Stop 03 · Test Planning & StrategyTopics · 3/9

Requirements Analysis for Testing

Part of the QA Testing Roadmap

In short

Many bugs are born before any code exists, inside a vague requirement. Reading requirements like a tester catches them when fixing costs one conversation.

Reviewing requirements specifically to identify what needs testing, spot ambiguity, and catch missing edge cases — QA often catches unclear or contradictory requirements before they become expensive bugs.

The purple blob holds a measuring tape around a shirt on a tailor's dummy, looking thoughtful.

Think of it like this

The tailor's questions

A good tailor doesn't just hear 'make a shirt'. He asks: slim or loose? Full sleeves? Which collar? Pocket or not? Each question avoids a wrong shirt later. Testers ask the same kind of questions about requirements.

Watch it happen

QA reviews a requirement

QA
Product
Developer

'Users can reset pwd'

1/5The product manager shares a one-line requirement for password reset.

The big ideas

What you need to know

Hunt for vague words

'Fast', 'user-friendly', 'secure', 'etc.' all need a concrete meaning before they can be tested.

Ask about the unhappy path

Requirements usually describe success. Ask what happens with errors, timeouts and wrong input.

Acceptance criteria

Turn each requirement into clear pass/fail conditions everyone agrees on before development.

Spot contradictions

If one page says 'guest checkout allowed' and another says 'login required', raise it now.

Save yourself the pain

Common mistakes

Oops

Waiting for the build to arrive before reading the requirement.

Do this instead

Review it as soon as it's written. Questions are cheapest before development starts.

Oops

Assuming what a vague requirement means.

Do this instead

Ask, and write the answer down where the whole team can see it.

Your mission

Interrogate a requirement

~20 min

Quick check

A requirement says 'The search should be fast.' What should QA do?

Go deeper

  1. 1Review a sample requirement and identify 2-3 ambiguities or missing edge cases.
  2. 2Learn why QA involvement early in requirements review (shift-left) catches cheaper-to-fix issues.
  3. 3Practice asking clarifying questions that would genuinely change how you'd test a feature.

More topics at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge