Functional vs non-functional

A functional requirement says what the product must do. A non-functional requirement, often shortened to NFR, says how well it must do it: how fast, how securely, for how many people, and for whom.

Non-functional requirements are also called quality attributes, and the standard list (ISO 25010) covers performance, security, reliability, usability, accessibility, compatibility and maintainability.

The short version is a door.

Think about a door.

Does it open? That is the functional question, and it has a yes or no answer. A tester can check it in a second.

Now the other questions. Does it open in half a second or four? Does it still work when five hundred people use it in an hour? Is it wide enough for a wheelchair? Can somebody force it from outside? Does it stay shut in a fire?

Every one of those is non-functional, and every one of them is where the expensive failures live.

The terms you will hear

• Functional requirement. A behaviour: the basket totals correctly, the email sends.
• Non-functional requirement (NFR). A quality condition: under two seconds, keyboard accessible, encrypted at rest.
• Quality attribute. The same idea in architecture language. Performance, security, reliability and the rest.
• Percentile. How the slowest users are measured. A p95 of 3 seconds means 5 in 100 waited longer.
• WCAG. The accessibility standard most legal requirements point at.
• Load, soak and spike. Performance tests for normal traffic, sustained traffic and sudden bursts.

The two kinds of question

Functional checks come from the story. Add to basket, apply the code, receive the email. They are the acceptance criteria, and they are what most suites contain.

Non-functional checks come from conditions the story never mentions.

• Performance. How fast, under what load, at which percentile.
• Security. Can somebody see or do what they should not.
• Accessibility. Can it be used with a keyboard, a screen reader, a magnifier.
• Privacy. What data is stored, for how long, and who can read it.
• Reliability. What happens when a dependency is slow or gone.
• Compatibility. Which browsers, devices and screen sizes.

Why these are the expensive ones

A functional bug annoys one person at a time and gets fixed in a sprint.

A non-functional failure arrives all at once and in public. A page that takes nine seconds on a phone loses customers who never file a bug. A form nobody can use with a keyboard is a legal exposure in several countries. A leak of one customer's data to another is a headline rather than a ticket.

They are also structural, so they are expensive to fix late. Performance and security choices are made in the design, which is why a tester who raises them early is worth several who find them at the end.

How to test all four without specialist tools

1. Performance: measure one journey on a real phone. Load the page, add to basket, check out. Note the seconds. A number beats an impression, and a repeated number beats a single one.
2. Security: try the boring cases. Log in as one customer and ask for another customer's order by changing the id. It is the cross-account test from jailbreaks and exfiltration. Check whether a logged-out user can reach a private page by pasting the URL.
3. Accessibility: unplug your mouse. Complete the main journey with the keyboard only. Then run the free axe browser extension. Those two steps catch most of what matters.
4. Privacy: ask what is stored and for how long. Then look at what you personally copied into a spreadsheet while testing, which is often the real answer.
5. Reliability: turn something off. Block the payment sandbox, or throttle the network to 3G, and see whether the interface tells the truth about what happened.
6. Write the numbers into the plan. Once a target exists, it is testable forever, which is what the risk table and the test plan are for.

A worked example

For example, here is one afternoon on the gift-card feature at Willow Books, with no specialist tooling at all.

Six defects, two gaps and one uncomfortable finding about my own testing habits, in one afternoon, with a phone and a free browser extension. Two of them are the kind that end up in a newspaper.

How to show you know it

• A number where there was none. "Checkout takes 3.1 seconds on 4G, and no requirement exists." That single line often creates the requirement.
• A keyboard-only run. Cheap, repeatable, and it finds real exclusions. Worth its own exploratory session.
• An identifier you changed in a URL. The most valuable fifteen minutes in this topic, every time.
• A privacy question about your own process. Noticing the customer data in your own spreadsheet is a mark of a professional.