Functional vs Non-Functional Testing

Most QA engineers start their careers testing features. Can the user log in? Does the cart total calculate correctly? Is the order saved in the database? That is functional testing — and it is essential. But a system can pass every single functional test and still be completely unusable in production. That is the gap non-functional testing fills.

The core distinction

Functional testing asks: does it work? You define an input, you define the expected output, and you verify the system produces it. The spec drives everything. Every test has a clear pass or fail.

Non-functional testing asks: does it work well enough? The behaviour may be correct, but is it fast enough, secure enough, resilient enough, accessible enough? These are the quality attributes that determine whether a product is actually usable — not just technically functional.

The difference matters because failing non-functional standards is not a minor polish issue. It is a product failing its users.

The "-ilities" you need to know

Non-functional concerns are sometimes called the "-ilities" because most of them end that way. This course covers the ones that matter most for QA engineers:

• Performance — how fast and how well the system handles load
• Security — how the system protects data and resists attack
• Accessibility — how usable the system is for people with disabilities
• Usability — how well real users can accomplish their goals
• Compatibility — how the system behaves across browsers, devices, and operating systems
• Reliability — how consistently the system stays up and recovers from failure
• Localisation — how the system adapts to different languages, regions, and cultural conventions

Each of these deserves its own deep-dive — and dedicated courses exist for the most important ones. This course gives you the overview: what each type is, when to test it, and which tools to reach for.

Why non-functional bugs are expensive

Non-functional failures look different from functional ones. A functional bug usually has a clear symptom — "the button does nothing" or "the total is wrong." Non-functional bugs are often invisible until they cause damage:

• A site that loads in 8 seconds on a mobile network technically works — and loses 53% of visitors (Google's measured threshold for mobile bounce rate).
• A form that skips WCAG keyboard accessibility technically functions — and is legally actionable under the ADA, EAA, and UK Equality Act.
• An API that collapses under 500 concurrent users passes all your functional tests — and takes down production on Black Friday.
• A login form vulnerable to SQL injection accepts valid credentials correctly — and exposes your entire user database when exploited.

None of these bugs would appear in a standard functional test run. All of them are production bugs.

Non-functional testing as a career differentiator

Most junior QA engineers are strong at functional testing. The path to senior roles — and to more interesting work — runs through non-functional testing. A QA engineer who can write a k6 load test, run an OWASP ZAP scan, conduct a keyboard accessibility audit, and specify measurable non-functional requirements is a fundamentally more valuable hire than one who cannot.

You do not need to master all of these at once. This course gives you a working understanding of each type, enough to know when to apply it and where to go deeper.

⚠️ Common mistakes

• Treating non-functional as optional polish. Performance, security, and accessibility are not final-sprint extras — they are first-class requirements. Retrofitting them after launch is far more expensive than testing for them during development.
• Setting no measurable targets. "The app should be fast" cannot be passed or failed. "The homepage must load in under 3 seconds at p95 under 500 concurrent users" can be. Vague requirements produce vague results.
• Assuming functional coverage means the system is ready. A 100% passing test suite says nothing about performance, security, or accessibility. You need separate strategies for each.

🎯 Practice task

Choose any app or website you use regularly — your bank, an e-commerce site, a SaaS tool. Spend 20 minutes treating it as a new testing target.

1. List 3 functional tests you would write — specific input/output checks.
2. List one non-functional concern for each of the following categories: performance, security, accessibility, and compatibility. Write each as a question ("Can the checkout form be navigated by keyboard alone?").
3. For each non-functional concern, decide: would your functional tests catch it if it were broken? The answer will almost certainly be no.

That gap — between what functional tests cover and what non-functional tests cover — is what the rest of this course teaches you to close.