Stop 02 · Manual Testing FundamentalsTopics · 5/11

Test Case Writing

In short

A test case is only useful if someone else can run it and get the same answer. Clear test cases make you trustworthy and save your team hours.

Writing a clear, repeatable test case — preconditions, steps, expected result — so anyone (not just the author) can execute it consistently and know exactly what a pass or fail looks like.

The purple blob holds up a recipe card next to neatly arranged ingredients on a kitchen counter.

Think of it like this

A recipe card for someone else

A good recipe card lists ingredients, gives steps in order and says how the dish should look and taste. Your roommate can follow it without calling you. A test case is a recipe card for checking one behaviour.

Watch it happen

Vague vs clear test case

Vague

'Check login works'
No test data given
No expected result

Clear

One behaviour per case
Exact data and preconditions
Expected result anyone can verify

If two testers could run your case and disagree on pass or fail, rewrite it.

The big ideas

What you need to know

ID and clear title

A title like 'Login fails with wrong password' tells you what's tested before you open it.

Preconditions

What must be true before step 1: a user exists, cart has two items, the feature flag is on.

Small numbered steps

One action per step, with exact data. 'Enter riya@test.com', not 'enter an email'.

Expected result

Describe exactly what should happen, from the requirement. That's what makes pass or fail obvious.

See it in code

Walk through the code

text

1ID:            TC-LOGIN-0042Title:         Login fails with wrong password3Precondition:  User riya@test.com exists and is active4Test data:     Password = Wrong@1235Steps:6  1. Open /login7  2. Enter riya@test.com and Wrong@1238  3. Click "Log in"9Expected:      Error "Email or password is incorrect"10               User stays on /login, not logged in

1/4A unique ID for tracking, and a title that says the behaviour.

A complete test case. Anyone on the team can pick it up and run it in a minute.

Save yourself the pain

Common mistakes

Oops

Cramming five checks into one test case.

Do this instead

One behaviour per case. When it fails you know exactly what broke.

Oops

Writing expected results like 'it should work properly'.

Do this instead

Write the exact message, page or value the requirement promises.

Your mission

Write five real test cases

~30 min

Quick check

Which expected result is best?

Go deeper

1Write 5 test cases for a real feature you use, including preconditions and expected results.
2Learn why vague expected results ('it should work') make a test case nearly useless.
3Practice writing steps specific enough that someone unfamiliar with the feature could follow them.