To say whether something is a bug or not, you need to know how it should work. That "how it should work" is written in requirements — the task description, user story, design mockup, or analyst's notes. Testing against requirements means verifying that the product does exactly what they describe, and knowing how to read and challenge those requirements.

The paradox of the job: the most expensive bugs are introduced not in code but in requirements — when something was misunderstood or never described at all. That's why a good tester starts work not with the product but with the requirements, and often catches problems before any code exists.

What requirements are

Requirements are a description of what should work and how. They come in several forms:

  • User story — a brief description from the user's point of view: "As a customer, I want to…"
  • Acceptance criteria — a concrete list of conditions that must be true for the task to count as done. For example: "correct password → login; wrong password → error message; three failed attempts → 5-minute lockout."
  • Mockups (design) — what it should look like on screen.
  • Task description, comments, verbal agreements.

For a tester, the gold standard is acceptance criteria: they translate almost directly into test cases. Each criterion is at least one check.

A good requirement is testable

The key property of a requirement is testability: you can say unambiguously whether it's met or not. Compare:

  • Bad: "The page should load quickly." What is "quickly"? Not testable.

  • Good: "The page loads in under 3 seconds." Testable: measure it, compare.

  • Bad: "The password must be strong."

  • Good: "The password must be at least 8 characters, containing at least one digit and one letter."

If you read a requirement and can't think of a check for it — that's a sign the requirement is bad. And that's your cue to ask a question. A requirement that can't be tested can't be implemented correctly either — people will interpret it any way they like.

Asking questions is part of the job

Requirements are almost always incomplete. The awkward edge cases aren't described because the author was thinking about the happy path. Your strength is asking questions that expose the gaps:

  • "What if the user clicks the button twice?"
  • "What if the order is cancelled after payment?"
  • "Is there a maximum length for this field?"
  • "What should show if the list is empty?"
  • "What if the internet drops in the middle of the operation?"

Ask these questions before the code is written — to the analyst, the manager, or whoever wrote the task. A gap found at this stage costs ten minutes of conversation. The same gap found in production is an incident. That's why testers are valued not just for the bugs they find, but for the good questions they ask.

Traceability matrix — missing nothing

When there are many requirements, it's useful to map them to test coverage in a table: requirements (or acceptance criteria) on the left, which test cases cover them on the right. This table is called a traceability matrix. It answers "is everything required actually covered by tests?" and shows gaps immediately: a requirement exists, but no test case covers it.

As a beginner you don't need to build a formal traceability matrix, but keep the idea in mind: every requirement must be verified by something — otherwise it's easy to "test" a product while forgetting half of what it was supposed to do.

Where this applies

Requirements are the starting point for all your work: test cases come from them, they let you tell a bug from "working as intended," and they tell you what to test in the first place. A tester who can read requirements, spot holes in them, and ask the right questions at the right time saves the team more than anyone — they put out fires where they're cheapest, before any code is written.

Where beginners stumble:

  • Testing "as it seems right" without checking the requirements — then arguing about bugs that are actually "working as intended" (or the opposite).
  • Staying silent when a requirement is unclear instead of asking. An unclear requirement is a future bug.
  • Only testing what's explicitly written and missing the awkward edge cases that aren't in the requirements but will absolutely happen to real users.

What to learn next. Requirements go deeper than they seem: requirement levels and properties will give you a checklist for evaluating them, and requirements review — the checking techniques and the skill of asking questions that get substantive answers.