Steps to reproduce: the 8 mistakes behind every "cannot reproduce"

"Cannot reproduce" is the most frustrating message a tester can receive. You saw the bug. You know it is real. But the developer followed your steps, saw nothing wrong, and closed the ticket.

Almost always, the bug is real and the steps were incomplete.

Steps to reproduce are the heart of a bug report. If a developer cannot see the bug on their own screen, they cannot fix it. This guide covers the eight mistakes that cause this, and how to fix each one.

Short version

Start from a clean, known state — not from wherever you happened to be.
Number your steps. One action per step.
Use the exact text on the button, not your description of it.
Include the data you typed, not "some text".
Say which account and role you used.
Mention timing if speed matters.
End with what you saw, not what you expected.

What "steps to reproduce" actually means

Steps to reproduce are a set of instructions that let another person see the same bug on their own computer.

That is a higher bar than most people realise. The other person does not have your browser tabs, your test account, your half-filled form, or your slow WiFi. They start from zero.

Your steps must carry them from zero to the bug.

Mistake 1: Starting in the middle

This is the biggest one by far.

Bad steps

Click Save

See the error

Where were you? What page? Were you logged in? What had you already filled in?

The developer opens the app, sees a login screen, and immediately stops.

Good steps

Open https://app.example.com/login in Chrome

Log in as [email protected] (role: Editor)

Go to Settings → Profile

Clear the "Phone number" field so it is empty

Click Save changes

Every bug report should start from a state anyone can reach: a logged-out browser, a fresh page, a known URL.

Rule: step 1 should always be something like "Open [URL]" or "Open the app and log in as [account]".

Mistake 2: Combining several actions into one step

Bad

Fill in the form and submit it, then check the dashboard

That is at least four actions. If the bug happens at action two, the developer will not know.

Good

Enter Test Order 1 in the "Order name" field

Select Express from the "Shipping" dropdown

Leave the "Notes" field empty

Click Create order

Click Dashboard in the left menu

One action per step. It feels slow to write. It is much faster to read.

Mistake 3: Describing buttons instead of naming them

Bad 3. Click the blue button at the top

Which blue button? On the developer's screen the theme might be different, or there might be three blue buttons.

Good 3. Click Publish now (top right of the page)

Use the exact label, in bold. Add the position in brackets if it helps. If the button has no label, describe the icon: "Click the trash icon next to the row".

Mistake 4: Hiding the data you used

Many bugs only happen with certain data. If you write "enter a name", the developer will type "John" and see nothing wrong.

Bad 2. Enter a customer name and save

Good 2. Enter the customer name O'Brien-Smith (note the apostrophe and hyphen)

Special characters, very long text, empty fields, emoji, numbers with commas, and non-English letters are all common bug triggers. If you used one, say so — and point it out.

Also include:

The file you uploaded (name, type, size)
The exact date you picked
The quantity, price, or amount
The search term you typed

If the data is private, replace it with fake data that has the same shape, and say what you changed.

Mistake 5: Forgetting the account and role

Software behaves differently depending on who is logged in.

Always include:

The account or username you used (a test account, never a real password)
The role or permission level (Admin, Editor, Viewer, free plan, paid plan)
The team, workspace, or organisation if the app has them

Log in as [email protected] (role: Viewer, workspace: Acme Demo)

Bugs that only appear for one role are extremely common, and they are invisible to a developer who always tests as Admin.

Mistake 6: Ignoring timing and speed

Some bugs only appear when things happen fast, or slow, or in a certain order.

Things worth mentioning:

Speed: "Click Save twice quickly (within one second)"
Waiting: "Wait for the spinner to finish before clicking"
Idle time: "Leave the page open for 30 minutes, then click Save"
Network: "Set network throttling to Slow 3G in DevTools first"
Order: "Open the second tab before saving in the first tab"

If you can only reproduce it sometimes, timing is usually the reason. Try to notice what was different on the times it worked.

Mistake 7: Writing the expected result inside the steps

Bad 5. Click Save and the total should update to $49.99 but it stays $0.00

Now the steps and the result are mixed together. It becomes hard to read and hard to follow.

Keep three separate sections:

Steps to reproduce

Expected result The order total updates to $49.99.

Actual result The order total stays at $0.00. No error is shown.

This separation is the single easiest improvement you can make to any bug report.

Mistake 8: Not testing your own steps

Before you file the ticket, do this: open a private or incognito window and follow your own steps exactly, word for word. Do not use knowledge that is only in your head.

You will find a missing step almost every time.

This takes two minutes. It saves a day of back-and-forth.

A full example

Here is a complete, well-written reproduction section.

Environment Chrome 141 on Windows 11 · Staging build 4.7.2 · Account [email protected] (role: Viewer)

Steps to reproduce

Open https://staging.example.com/login in Chrome

Log in as [email protected]

Click Projects in the left menu

Open the project named Website Redesign

Click the Export button (top right)

Select CSV in the dialog

Set the date filter to 01 Jan 2026 – 31 Jan 2026

Click Download

Expected result A CSV file downloads containing the 14 tasks from January 2026.

Actual result A CSV file downloads, but it contains only the header row and no data. No error is shown in the interface. The console shows TypeError: Cannot read properties of undefined (reading 'rows').

How often 5 out of 5 attempts.

Notes Works correctly if no date filter is applied.

That last line — "works correctly if no date filter is applied" — is worth more than the rest of the report combined. It tells the developer exactly where to look.

Include what happens between the steps

Attach the evidence that shows the failure, not just describes it:

A screenshot or short video of the final screen
Console errors from the browser developer tools
Failed network requests, with the response body
The build or version number

Writing all of this by hand is slow, which is why most testers skip it. Bug reporting tools such as Crosscheck record the console log, network activity, and browser details automatically while you reproduce the bug, so this section fills itself in.

Frequently asked questions

How many steps is too many? If you need more than about ten, check whether some steps are just setup. Move those into a "Preconditions" section, and keep the steps focused on the actions that trigger the bug.

What if I cannot reproduce it a second time? Say so clearly: "Reproduced 1 out of 8 attempts." Then write everything you remember about the one time it happened. An honest, partial report is far better than no report.

Should I write steps for obvious things like logging in? Yes. It costs you one line, and it removes all doubt about which account was used.

Do developers really read all the steps? They read them when the bug matters and the steps look reliable. Numbered, clean steps signal "this is a real bug", which makes people more likely to start.

What if the bug only happens with production data? Say that explicitly, and describe the shape of the data without sharing private details. For example: "Only happens for customers with more than 500 orders."