Turning Requirements Into Testable Statements
Why vague requirements produce vague tests, and how to rewrite an ambiguous requirement into something you can actually design test cases against.
What you'll learn
- Identify ambiguity, missing information, and untestable phrasing in a requirement
- Rewrite an ambiguous requirement as a precise, testable statement
- Generate clarifying questions a requirement's ambiguity should raise
Prerequisites
Explanation
"The system should respond quickly." A tester handed this requirement has nothing to test against — quickly compared to what? Under what load? Measured where? A requirement that cannot be tested is not really a requirement yet; it is a hope.
Requirements analysis, for a tester, means reading a requirement the way a skeptical reader reads a contract: what does this actually commit to, and what is left dangerously open? Three failure patterns show up constantly:
Ambiguity — a word admits more than one reasonable interpretation. "The user should be logged out after a period of inactivity" — five minutes? An hour? Does moving the mouse count as activity, or only clicks?
Missing information — the requirement is silent about a case that will definitely occur. "Users can upload a profile photo" says nothing about file size limits, allowed formats, or what happens when the upload fails partway through. Silence is not a specification; it's a gap a real user will eventually fall into.
Untestable phrasing — a requirement uses subjective or unmeasurable language. "The interface should be intuitive" cannot be verified by any concrete test — there is no observable pass/fail condition. It needs to become something like "a new user can complete checkout without external help in under 3 minutes, verified via a usability session."
The fix is always the same move: turn a vague sentence into a precise, measurable, falsifiable one, then write down the questions the ambiguity raises so a real stakeholder can answer them before code gets written — not after a defect report is filed. This is cheaper for everyone: a clarifying question costs a Slack message; a defect found in production costs a support ticket, a hotfix, and a customer's trust.
Example
A vague requirement rewritten as a precise one, and a small function that encodes the precise version so it can actually be checked.
// Vague: "Passwords must be strong."
// Precise: "A password is valid only if it is at least 8 characters
// AND contains at least one digit."
function isValidPassword(password) {
return password.length >= 8 && /\d/.test(password);
}
console.log(isValidPassword("short1")); // false — too short
console.log(isValidPassword("longenough")); // false — no digit
console.log(isValidPassword("longenough1")); // trueTry it yourself
Change the precise requirement's rule below (e.g. require 10 characters instead of 8), then re-run to see which examples change verdict.
Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.
Guided exercise
Guided exercise
Requirement: "The search box should return results fast." Identify its problem by setting isAmbiguous, hasMissingInfo, and isUntestable to true or false (more than one may be true).
Checks: recognizes ambiguity · recognizes missing information · recognizes it is currently untestable
Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.
Stuck? Get a hint.
Independent exercise
Independent exercise
Rewrite the vague requirement "the search box should return results fast" as a precise, testable one by writing it as a string in preciseRequirement. It must include a concrete time limit and a measurement condition (e.g. under what load or on what connection).
Checks: includes a concrete, measurable time limit · describes the condition the limit applies under
Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.
Stuck? Get a hint.
Common mistakes
- Accepting a vague requirement as-is and deferring the ambiguity to "we'll figure it out during testing" — that just moves the cost later and makes it more expensive.
- Treating silence in a requirement as "anything is acceptable" instead of a genuine gap that needs an explicit decision.
- Rewriting a requirement to be precise but choosing an arbitrary number nobody agreed to, instead of raising it as a question for the actual stakeholder.
Knowledge check
Takeaway
A requirement you cannot design a concrete test case against is not finished — turning it into a precise, measurable statement is a testing skill, not busywork.
Summary
This lesson covered the three common requirement failure patterns — ambiguity, missing information, and untestable phrasing — and practiced rewriting a vague requirement into a precise, testable one.
References
Your notes
Notes save automatically.
Finished this lesson?
Mark it complete to track your progress and schedule a future review.
AI tutor
The optional AI tutor isn't enabled in this deployment. All lessons, exercises, quizzes, and search work fully without it.