What this path covers that functional automation does not
Functional tests answer "does it work?". This path covers the questions that cause outages and incidents: is it fast enough under load, is it secure, can everyone use it, does it still look right, and will it stay up. Each lesson is written for testers, so it focuses on what you can check and automate rather than on deep specialist theory.
Start with performance testing fundamentals, which uses k6, then JMeter basics. Security testing basics and the OWASP Top 10 for testers follow. Accessibility testing, visual regression testing and mobile testing cover the user-facing risks, and reliability engineering and test architecture close the path at system level.
Common mistakes in non-functional testing
- Reporting average response time. Averages hide the slow tail; report p95 and p99 against an agreed threshold.
- Load testing with a closed model when real traffic arrives independently of response time, which hides queueing.
- Running security tools against systems you are not authorised to test. Get written permission first.
- Assuming an automated accessibility scan is a full audit. Tools catch only part of WCAG failures; keyboard and screen reader checks are still needed.
- Visual baselines captured on a developer laptop and compared in Linux CI, so every font renders differently.
How this maps to senior interviews
Senior SDET and lead rounds often include a system design question such as "design the test strategy for a payments service". Interviewers look for risk-based choices across layers, including performance, security and observability, not only UI automation. Practise with the system design for SDET questions, the performance testing questions and the security testing questions. Glossary entries such as percentile latency and IDOR are useful quick refreshers.
Suggested study plan
Lessons in this path are largely independent, so start with the area your team is weakest in. Allow a week per area if you try the tools as you read: run a small k6 script, add an axe-core check to an existing Playwright test, and capture one visual baseline in Docker.
Write down what you find as risks with an owner and a proposed check, not as a list of tool outputs. That habit, more than any single tool, is what the move from automation engineer to quality engineer looks like.