Non-functional testing
Non-functional testing is testing that checks how well a system behaves rather than what it does: its speed under load, its security, its accessibility, its compatibility across browsers and devices, and its recovery from failure. Functional testing asks whether a feature works; non-functional testing asks whether it works acceptably for the people and conditions it will meet.
The longer version
A non-functional test measures a quality against a threshold somebody agreed in advance. A performance test loads the checkout with a set number of concurrent users and records response times, and the test passes only if the recorded times sit under the limit in the requirements. A security test probes for known classes of weakness. An accessibility test checks the page against a published standard. Without the threshold there is no pass or fail, only a measurement, which is why non-functional testing depends on requirements written as numbers and conditions rather than adjectives like fast or robust.
The contrast with functional testing is the shape of the question. Functional testing has a binary oracle: the order was placed or it was not, the total matched or it did not. Non-functional testing has a scale, and the pass line is a decision, not a fact. The same page that passes for a marketing site fails for a trading desk. Teams that treat the two identically write non-functional requirements they cannot test, such as a site that should be responsive, and discover at release that nobody can say whether it was met.
Non-functional defects surface late. Functional defects surface early because a feature either works in the demo or it does not; load, scale and hostile input do not exist in a development environment, so the defects they cause appear only once such an environment does, and the fix is often architectural: a query that was fine at a hundred rows is unusable at a million, and no small patch corrects it. A team that schedules its performance run for the last week before launch has left itself no time to act on what it finds.
In a test plan, non-functional testing is listed by quality attribute, with a named owner and a named environment for each, because most of them need production-shaped infrastructure to mean anything. Compatibility and accessibility can run earlier and cheaper than performance and security, which is the argument against cutting them when the schedule slips.
Common questions
What are examples of non-functional tests?
Non-functional tests measure how well the system behaves under a stated condition: a load test that holds the expected number of concurrent users and records response times, a cross-browser run of the checkout on the browsers the customer base actually uses, a screen-reader pass over a form, a timed run of the largest export, and a recovery test that stops a server mid-transaction and checks that no data was lost. Each passes or fails only against a threshold written down beforehand.
What are the types of non-functional testing?
The common ones are performance and load testing, security testing, accessibility testing, compatibility testing across browsers and devices, usability testing, and recovery or resilience testing. Each measures a distinct quality attribute, needs its own tooling and often its own environment, and is owned by whoever can judge its threshold.
When should non-functional testing be done?
Before the architecture is fixed, which is earlier than it is usually scheduled. Accessibility and compatibility checks can run on every build. Performance and security need a production-shaped environment, so they run once one exists, but the first run should be far enough before release that an architectural fix is still possible. A performance run in the last week before launch only reports the problem.
Who is responsible for non-functional testing?
Ownership is split by quality attribute rather than held by one role. Performance testing usually sits with a performance engineer or the developers who own the service, security testing with a specialist or an external assessor, accessibility and compatibility with the QA team, and the thresholds with product and architecture, who decide what acceptable means. The test plan names an owner per attribute so that none is assumed to be somebody else's.
Can non-functional testing be automated?
Most of it is automated by necessity, because a person cannot generate heavy concurrent load or check every page for contrast failures by hand. Load tests, security scans, accessibility scans and cross-browser runs all execute from tools on a schedule. What stays manual is the judgement: setting the threshold, reading a result that sits near it, and the assistive-technology pass that no scanner can perform.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.