Requirements, User Stories & Acceptance Criteria

Testing, you know by now, is comparing what software does against what it should do. Which raises a question nobody can dodge: where does the "should" come from? The answer is requirements — and reading them critically is a core QA skill, because half the bugs you'll ever prevent are ambiguities you catch in a document, not defects you catch in an app.

A tailor makes the stakes plain. "Make it fit nicely" is an order no one can check a suit against; measurements are. Your entire profession runs on the difference between those two order forms — and on noticing, before the fabric is cut, when you've been handed the first kind.

What a Requirement Is

A requirement is a statement of what the software must do — in any form: a formal specification document, a sentence in a chat, a sketch on a whiteboard, or the modern team's favorite, the user story. Whatever the form, it plays the same role in your work: it is the should in every comparison you'll ever make. When a requirement is clear, testing has solid ground. When it's ambiguous, every person downstream — developer, tester, support agent — fills the gap with their own guess, and the guesses don't match. Fernway's refund weekend was exactly that: a gap filled three different ways.

User Stories

Modern teams usually package requirements as user stories — short, structured sentences in the shape: As a someone, I want something, so that some benefit. For example: "As a traveler, I want to cancel my booking online, so that I don't have to call support." The three parts each earn their place. The who stops the team building for an imaginary everybody. The what names the capability. And the why — the part beginners skim — is the tester's secret weapon: if a built feature technically works but doesn't deliver the so that, something went wrong, and you're the person positioned to say so.

Acceptance Criteria: the Tester's Contract

A story is deliberately short — too short to test against. The testable part comes as acceptance criteria: the specific, checkable conditions that define when the story is done. For the cancellation story, they might read: a booking can be cancelled from the account page until 48 hours before check-in; after that, the cancel button is replaced with a "contact support" link; a cancelled booking refunds automatically to the original payment method; the traveler receives a cancellation email. Each criterion is a sentence you can hold the built feature against and get a yes or a no. That's the test: a good criterion has a yes-or-no answer. "Cancellation should be easy" doesn't; "cancellable until 48 hours before check-in" does.

Acceptance criteria are as close as the industry comes to a contract between product, development, and QA — which is why testers care so much about their wording, and why refinement (last topic) is where you fight for that wording politely.

Ambiguity Is a Defect

Now the skill itself. Read this requirement the way Petra first wrote it: "The promo discount applies to long stays." A trained tester's head fills with questions. How long is long — three nights? Five? Is exactly three "long"? What happens on a two-night stay — an error, a silent no-discount, a grayed-out field? And which discount wins when a member applies a promo code? None of these questions is pedantry. Each is a place where Omar's guess, Lucy's guess, and a traveler's expectation can differ — which is the exact anatomy of the refund weekend.

Finding the question nobody asked is testing — the static kind, done with a document sitting still. It's the highest-leverage work a junior tester does, and it produced the SUMMER15 criteria in the figure above: minimum three nights, no combining, clear error. Every number in that contract exists because someone asked.

When There Are No Requirements

And the junior reality this book won't pretend away: sometimes there's no story, no criteria, just "can you test this?" You are not helpless. You test against reasonable expectations — how similar products behave, what a sensible traveler would assume, how the rest of Fernway works (consistency is a requirement nobody writes down). You ask, wherever asking is possible. And — the professional move — you write down the expectations you tested against, right in your notes or bug reports: "assumed a cancelled booking should refund automatically, as competitor apps do." Now your assumption is visible, checkable, and correctable, instead of silently baked into your verdicts. Half the time, your written-down assumptions become the requirements the team never had.