Functional vs non-functional testing
Updated 2026-11-13 · 2 min read
Compare what a system does with measurable quality characteristics such as response time, usability and recovery. Includes a comparison table, concrete examples and an interview answer.
The difference in one table
| Aspect | Functional testing | Non-functional testing |
|---|---|---|
| Focus | Behaviour and business rules | Quality characteristics under stated conditions |
| Question | Does the feature produce the right outcome? | How well does the system operate? |
| Example | A successful payment creates one order | Checkout meets its agreed response-time target under load |
| Expected result | Specific output or state change | Measurable criteria or structured evaluation |
| Tools | Manual exploration, API or UI automation | Depends on the characteristic: load, accessibility, recovery and more |
Examples
Functional: submit an order with an invalid coupon. Check that it is rejected, the total remains correct and no payment starts. This tests a business rule.
Non-functional: run the checkout journey under an agreed workload and compare response times and error rates with agreed acceptance criteria. Separately, assess whether keyboard users can reach and understand the coupon error. These examine performance and accessibility, not just whether the coupon calculation is correct.
A useful requirement names the conditions and the evidence needed. “Checkout should be fast” is too vague to decide a pass or fail.
How to answer in an interview
Functional testing checks what the system does, including business rules and state changes. Non-functional testing evaluates quality characteristics such as performance, usability and reliability under stated conditions. For checkout, I check correct totals functionally and evaluate response times under an agreed workload separately. Both need observable acceptance criteria, and one journey can provide evidence for both.
Common confusion
Non-functional does not mean optional or impossible to automate. Also avoid treating security as a neat exclusive bucket: access-control behaviour can be tested as a functional rule, while broader security evaluation examines threats and resilience. State the objective instead of arguing over the label.
Likely follow-up: Can a feature pass functional tests and still be unusable? Yes: a correct checkout may be too slow or inaccessible in the intended operating conditions.
This is independent foundation-level learning material, not affiliated with ISTQB.
Quick answers
Is UI testing always functional?
No. A UI can be checked for behaviour, accessibility, usability or performance. The objective determines the classification.
Should non-functional work wait until the end?
No. Define the important characteristics early so design decisions and test environments can support them.
Sources
Want a project you can show in interviews?
The portfolio project kit walks you through testing a deliberately buggy app with Selenium or Playwright and API tests, then explaining it. The app itself is free.