Writing test cases and bug reports

Why this is a skill in itself

A tester is judged not by how much they found but by how clearly they described it. A bug nobody can reproduce gets closed as "cannot reproduce", and your work is wasted.

It's the first skill checked at interview: you'll be asked to describe any defect, and they'll watch what comes out.

The structure of a test case

A title. What exactly is being checked, in one phrase. "Login with valid credentials", not "Login check number 3".

Preconditions. What must be true before you start: the user is registered, the basket holds two items.

Steps. Numbered and specific. Not "go to settings" but "click the avatar in the top right, choose Settings".

Expected result. What should happen. One result per case.

The governing criterion: someone seeing the system for the first time should be able to execute it. If it requires your knowledge, the case is badly written.

The structure of a bug report

A title. The essence in one line: what fails, where, under what conditions. The title should tell someone whether to open it.

Bad: "Error in the form". Good: "Paying with an expired card freezes the form, no money is taken and no message appears".

Steps to reproduce. Numbered, starting from a clean state. The most important part.

Expected result. What should have happened.

Actual result. What happened instead.

Environment. Browser, version, device, account, time.

Attachments. A screenshot, a recording, the console error, the request identifier.

Severity and priority. How badly it breaks things and how urgently it needs fixing. These differ: a typo on the front page isn't critical but is urgent, because everyone sees it.

Bad examples, examined

"Registration doesn't work" — which part? No email arrives, the form crashes, the password is rejected? A developer will spend half an hour discovering what you already knew.

"The basket sometimes clears" — "sometimes" is useless. Conditions are needed: after which action, after how long, in which browser.

"The design is off on mobile" — a judgement instead of a fact. Needed: on this device in this browser the text overflows its container, screenshot attached.

Three bugs in one report — they'll be fixed and closed piecemeal and eventually lost. One problem, one report.

What sharply improves the chance of a fast fix

Reproducing first time. If the developer can't repeat it, they won't go further.

Saying when it broke. "Worked in the previous version" narrows the search enormously.

Minimal steps. Strip everything unnecessary: not ten actions but the three that suffice.

The impact on people. "Affects everyone paying by card" carries more weight than "serious bug".

How to practise

Take any service, find five problems and write each up to the structure above. Give it to someone who has never used that service and ask them to follow your steps.

If they managed, you can write bug reports. That's ready portfolio material and the best answer to "show us an example of your work".