beginner30 minby DevFox

Turning Requirements Into Test Cases

Read a feature description, find what it does not say, and turn it into cases someone else can run: preconditions, steps, expected result, and one behaviour per case.

Testing
QA

The ticket said: "Users should be able to reset their password." Nine words, one acceptance criterion — "reset works" — and two weeks in production before anybody noticed that the reset links never expired. Not "expired after a week". Never. A link mailed in March still worked in September.

Nobody decided that. It was simply never asked, so the code answered it by accident.

By the end of this lesson you will know how to interrogate a requirement until its gaps show, and how to turn what you learn into test cases somebody else could run tomorrow and get the same answer you did.

Reading what is not there

Take that sentence and treat it as a pile of unanswered questions. "Users should be able to reset their password."

Which users? Any registered account? What about one that has never verified its email, or is locked, or was deleted last week?
Reset it how? A link by email? A code? Security questions?
How long is that link valid, and what happens after?
Can the link be used twice?
If they request three resets in a row, do all three links work, or only the newest?
Can the new password be the same as the old one?
What are the password rules, and where is the user told them?
Does resetting log them out of their other sessions?
What does an unregistered email address get told?
How fast can somebody request resets before it looks like an attack?

Ten questions, none of them exotic, every one of which will be decided by somebody. The only real choice is whether they get decided deliberately now, or accidentally in code later.

Look at question nine again. "What does an unregistered email address get told?" has a right answer — the same message a registered one gets, because anything else lets a stranger discover who has an account. That is a security requirement, and it fell out of asking what happens in the unhappy case.

Four questions that find the gaps

You do not need a checklist of a hundred items. Four questions, run over any requirement, surface most of what is missing.

What is the exact rule?
Vague words hide decisions. Quickly, large, recent, valid, appropriate — each needs a number or a definition. "The link expires quickly" is not testable. "The link expires 60 minutes after it is sent" is.
What happens when it fails?
Requirements are written for success. What does the user see when the email cannot be sent, the token has expired, the account is locked, the network drops mid-request? Each is a behaviour somebody has to design — and if nobody designs it, the user gets a stack trace.
Who is allowed to do this?
Almost every feature has an authorisation dimension that goes unmentioned. Can a user reset another user's password? Can an admin? Should an admin be able to?
What else does this touch?
Features have consequences. Does resetting a password end active sessions, notify the user, appear in an audit log, invalidate API tokens?

Run all four, in this order, over any requirement you are handed

You will come out with a list of questions. Take them to whoever owns the feature. That conversation is the testing work, and the answers become your test cases.

Acceptance criteria that are testable

The answers should end up written down, in a form where "done" is not a matter of opinion. A common and effective shape is given / when / then:

Three properties make criteria like these worth writing. They are specific — 60 minutes, not "quickly". They are observable — somebody can look and see whether it happened. And they include the unhappy paths, which is where most of the value is.

From criteria to test cases

Acceptance criteria say what should be true. A test case is instructions for finding out, precise enough that two people running it independently get the same result.

The parts:

Five things separate a case that is useful from a case that is noise.

One behaviour per case. If a case verifies four things and the second fails, what is the result? "Partly passed" is not a status. Split it.

Preconditions stated, not assumed. "A verified account exists" is the difference between a case anybody can run and one only you can.

Steps that need no guessing. "Log in" is ambiguous — as whom? "Log in as a user with no projects" is runnable.

An expected result specific enough to fail. "The page looks correct" cannot fail honestly. "The page shows the message This link has already been used" can.

Data that is real and written down. Not "enter an invalid email" but "enter not-an-email". The next person should not have to invent the input, because they will invent a different one.

The vague case, and what it costs

Bad — cannot fail, and cannot be reproduced:

Good — one behaviour, real data, an observable result:

The bad version is common because it is fast to write, and it does damage in three ways. Two testers running it test different things, so the result means nothing. It can never legitimately fail, because "correctly" is whatever the runner decides. And when a bug does slip through, nobody can tell whether the case covered it — so nobody knows whether the suite has a gap or the product has a defect.

The good version takes ninety seconds longer to write and stays useful for years.

Choosing which cases to write

Even one requirement generates more cases than are worth having, so pick deliberately. A sensible order:

The happy path, once. It has to work, and if it does not, nothing else matters.
Each rule's failure case. Every "must" implies a case where it is violated. Expired link, wrong password, missing field.
The boundaries of any number or limit. That is the next lesson's whole subject.
The authorisation cases. Wrong user, no user, an admin.
The already-done cases. Twice, again, after a failure.
The empty and first-time cases. No data, new account.

Stop when the next case exercises the same code path as one you already have. Three invalid email formats reach one validation branch; a fourth costs time and adds nothing.

How much to write down

Detail should match how the case will be used. Over-formalising is a real failure mode, and an expensive one.

Run once, while exploring

Almost nothing.

A note of what you tried and what happened. The exploratory testing lesson covers this mode properly.

Living in a regression suite

The full form.

Different people will run it over years. Preconditions, exact data, exact expected result — everything the runner would otherwise have to guess.

About to be automated

The precision goes in the code.

Write an elaborate manual case and automate it and you now maintain two descriptions of one thing, which drift.

One behaviour, three different jobs, three different amounts of writing

The trap is writing hundred-step scripts for everything. Detailed cases are expensive to write, expensive to keep current, and they go stale silently. A suite of a thousand stale cases is worse than fifty accurate ones, because it produces confidence nobody has earned and nobody knows which are which.

Cheat sheet

Where to go next

You can turn a requirement into cases. The next lesson makes step three of that priority list systematic: how to choose which values to test when the possible inputs never run out, using equivalence classes and boundary values. They give the best return of anything in this course.

Before that, take a real requirement from something you work on and run the four questions over it. The number of decisions nobody has made is usually a surprise, and finding them is the job.