A requirements document says "the system must be highly available and performant". How do you turn that into something testable?
Show the full answer Hide the answer
What the interviewer is testing
Whether you can convert an aspiration into a quality attribute scenario with a number, a percentile and a condition.
The conversion
An NFR without a number constrains nothing and can never be tested. Each vague term must become a scenario with six parts: source, stimulus, environment, response, response measure, and the condition under which it holds.
| Vague | Testable |
|---|---|
| Highly available | 99.95% monthly availability measured as the ratio of successful to total requests at the gateway, excluding client errors |
| Performant | p99 latency under 300 ms for the order API at 1,000 RPS sustained, measured at the gateway with production-scale data |
| Scalable | Sustains 4× current peak with no more than 20% latency degradation, scaling within 3 minutes |
| Recoverable | RTO 30 minutes, RPO 5 minutes, demonstrated by a timed restore exercise each quarter |
| Secure | No critical or high vulnerabilities in deployed artifacts; all data encrypted at rest and in transit; annual penetration test with findings remediated to an agreed schedule |
The questions that produce the numbers
Ask the business rather than inventing them: what does an hour of downtime cost, and at what point do customers leave? What is the current traffic and its expected growth? What is the worst acceptable data loss? Which journeys matter most — availability targets almost always differ by journey, and a single system-wide number is usually wrong for everything.
The step that closes the loop
For each target, name the test that could falsify it, the environment it runs in, and when it runs. An NFR with no corresponding test is still an aspiration, however precisely it is written.
What a strong answer adds
Placing the falsifying test as early as possible — a spike against a skeleton in the first weeks is the cheapest moment to learn the design cannot hit the target. Scheduling all NFR validation before go-live means discovering an architectural problem when it is too late to change the architecture.
Common weak answers
Inventing numbers without asking the business, which produces targets nobody owns. Accepting the wording and testing what is convenient.