Understanding Requirements and Acceptance Criteria

Every test case you write is an answer to a question buried in a requirement. If the requirement is fuzzy, your tests will be fuzzy. If two requirements contradict each other, your tests can pass while the product is broken. The most undervalued skill in manual testing is reading a requirement carefully — and pushing back when it cannot be tested as written.

What requirements actually are

A requirement is a statement of what the system should do. They come in three flavours, and a great tester recognises all three:

• Functional requirements describe behaviour — "users can apply a discount code at checkout." These are the what.
• Non-functional requirements describe quality — "the page loads in under 2 seconds on 4G." These are the how-well.
• Business rules describe domain constraints — "a single discount code cannot be applied more than once per customer." These are the source of the most subtle bugs.

A requirement that mixes all three without separating them is a red flag — the team has not thought clearly about what testing it needs.

User stories and acceptance criteria

In agile teams, requirements typically arrive as user stories with acceptance criteria. The story explains who and why; the criteria explain what "done" looks like.

A common format is Given / When / Then:

Given I am a logged-in customer with items in my cart When I enter a valid discount code "SPRING10" and press apply Then the order total decreases by 10% and a confirmation message is displayed

That is a testable acceptance criterion. You can run it, observe the result, and answer pass or fail unambiguously. Compare to:

"Users can apply discount codes at checkout."

That is not a testable acceptance criterion. It is a feature description. As a tester you cannot tell whether "10% off" is required or just "some discount." You cannot tell what happens with an invalid code, an expired code, two codes, or an empty input. This is where your job starts. (BDD and ATDD are the formal names for the practice of writing requirements in this testable form.)

The cost of ambiguity

"The system should be fast" is the canonical bad requirement. Fast on what device? Under what network? At which percentile of users? On the first visit, when the cache is cold? Fast is not measurable, which means there is no behaviour you can verify. A good version would read: "The product page loads in under 2 seconds at the 95th percentile on a 4G connection."

Ambiguous requirements are not just an annoyance — they are how production bugs slip through. If neither the developer nor the tester knows what "correct" means, two reasonable people can build, test, and ship a feature that is wrong by one party's interpretation. The fix is not to argue at release time. The fix is to clarify at refinement time.

From a vague story to a tester's questions to a real plan

A real example: the discount code field

Imagine an e-commerce team writes: "Users can apply a discount code at checkout." A tester who reads it carefully will surface at least these questions:

• Expired codes — rejected, or silently ignored?
• Case-sensitive? SPRING10 vs spring10?
• Multiple codes in one order, or only one?
• Empty string, or just whitespace?
• Special characters — does SPRING-10 validate?
• Maximum discount — can a stacked promo result in a negative total?
• SQL injection — what happens with '; DROP TABLE users; --?
• Before or after tax, and before or after shipping?

None of those questions are in the original story. All must have answers before you can test responsibly. A great tester writes them up, takes them to the PM and dev, and refines the acceptance criteria before a line of code is written — shift-left in practice. The 30-minute clarification meeting costs roughly 1% of what the same questions cost as support tickets after launch.

Spotting gaps and contradictions

Three patterns reliably appear in immature requirements:

• Gaps. Behaviour that is not specified for a path the user can take. "What happens if the user cancels mid-payment?" usually has no answer in the spec.
• Contradictions. Two requirements that disagree. "Customer can use one discount code" and elsewhere "promotional codes can be combined with member discounts."
• Implicit assumptions. "The system sends an email" — over what timeframe? Synchronously, before the page loads? Asynchronously, within 60 seconds? The spec rarely says.

When you find any of the three, file a question with the PM before you write a single test case.

⚠️ Common mistakes

• Testing only what the story explicitly says. The story is the floor of your testing scope, not the ceiling. The questions the story does not answer are exactly where bugs live.
• Assuming silence means consent. "The spec did not mention what happens with an empty string, so I will skip that case." If a real user can do it, a real test case must cover it. Ask the PM what the spec meant; do not invent an answer.
• Confusing user stories with acceptance criteria. A story explains intent; criteria define done. A team that ships with stories and no criteria is shipping with the testing scope undefined — and you will find out at release time.

🎯 Practice task

Pick any feature on a website you use regularly — a search bar, a sign-up form, a "save for later" button. Spend 25 minutes reverse-engineering its requirements:

1. Write the story in one sentence, the way a PM would (e.g., "Users can save items for later from the product page").
2. List at least 12 clarifying questions a tester should ask before testing — covering input validation, error states, permissions, edge cases, performance, and security.
3. Pick the three highest-impact questions and write Given / When / Then acceptance criteria that would make those behaviours testable.
4. For each acceptance criterion, write one positive and one negative test case in plain English.

You now have a worked example of how a one-line story becomes a real test plan. The next lesson takes that material and shows you how to organise it into a plan a manager can actually read.