Blog › Tutorials

Steps to Reproduce a Bug: Examples (2026)

🔧 Tutorials · 8 min read · October 9, 2026
Why "I Can't Reproduce It" Is Almost Always a Steps Problem 5 Rules for Steps That Work How Granular Should the Steps Be? 5 Complete Examples Example 1: Login and authentication (5 steps) Example 2: Payment and coupons (6 steps) Example 3: Mobile touch (5 steps) Example 4: API and data (4 steps) Example 5: Intermittent bug (with probability and timing) 7 Mistakes That Invalidate Your Steps Pre-Submit Checklist FAQ Write the Steps Yourself; the Evidence Can Be Automatic Further reading

Why "I Can't Reproduce It" Is Almost Always a Steps Problem

Good steps to reproduce = a clear starting point + one action per step + real data + what you observed at each step. If someone can read them aloud and land on the same screen, the steps are good enough. Below are 5 rules, a granularity test, 5 complete examples (including how to write up an intermittent bug), and a checklist to run before you submit.

When a developer replies "I can't reproduce it", it's rarely reluctance. Something is missing from the steps, and it's usually one of three things:

  • The starting point is missing: no preconditions written down. You were signed in as an enterprise account, the developer used a personal one — two different code paths.
  • Actions got merged: one step says "fill in the form and submit", but the bug happens in the autosave between filling and submitting.
  • Data is missing: placeholder descriptions instead of real values — and the bug only appears when the email contains a + sign.

    • In one line: steps aren't a record for you, they're a route for someone else.

    5 Rules for Steps That Work

  • State the starting point: login state, data state and entry URL belong in the preconditions, not wedged into step 1.
  • One action per step: each number does exactly one thing, so a reader can check them off.
  • Use real data: write user+test@x.com, not "an email address".
  • Note what you observed (recommended): after key steps, add "at this point the page shows X" so the developer can see where things start to diverge.
  • Put the environment in the environment field, or declare it on the first line: browser, OS, device and viewport width — drop one and reproduction may fail.

    • How Granular Should the Steps Be?

    Granularity Example Problem
    Too coarse "Open checkout, remove an item, notice the count is wrong" Three actions in one sentence — nobody can tell where it breaks
    Just right "1. Go to /cart 2. Click Delete next to the product 3. Look at the badge at the top of the page" One action per step, each one verifiable
    Too fine "1. Move the pointer over the button 2. Press the left mouse button 3. Release it" Physical actions split apart, which is harder to read, not easier

    The test: after writing, ask two questions. ① Could someone else reach the same screen without looking at my screenshot? ② Can a developer tell within two minutes whether this is front-end, API or data? Two yeses means the granularity is right.

    5 Complete Examples

    Example 1: Login and authentication (5 steps)

    Preconditions: account test@example.com already registered and in good standing. Environment: Chrome 120 / macOS 14 / desktop / 1920×1080 / incognito window.

  • Open https://app.example.com/login
  • Enter test@example.com with the correct password
  • Enter a wrong image CAPTCHA three times in a row
  • On the fourth attempt, enter a valid CAPTCHA and click "Sign in"
  • Observe the message shown on the page

    • Expected: a "CAPTCHA incorrect, please retry" message, with the account staying unlocked. Actual: shows "Account locked, try again in 24 hours" — and this time the CAPTCHA was correct.

    Example 2: Payment and coupons (6 steps)

    Preconditions: 2 items in the cart totalling $1,299; the account is on the enterprise plan. Environment: Chrome 120 / Windows 11 / desktop / 1440×900 / enterprise account.

  • Open /cart and confirm the total is $1,299
  • Click "Checkout"
  • Enter the coupon code SAVE100 (expired three days ago) in the coupon field
  • Click "Apply"
  • Observe the banner at the top of the page and the state of the cart
  • Refresh the page and observe again

    • Expected: a "coupon expired" message, with the cart unchanged. Actual: shows "coupon applied" and removes $100; the moment "Apply" is clicked, both items vanish from the cart.

    Example 3: Mobile touch (5 steps)

    Preconditions: signed in with 1 item in the cart. Environment: iPhone 14 / iOS 17.2 / Safari / viewport 390×844.

  • Open https://shop.example.com/cart
  • Scroll to the address form at the bottom of the page
  • Tap the "Recipient name" field to bring up the keyboard
  • Look at the "Place order" button above the keyboard
  • Try to tap that button

    • Expected: the "Place order" button moves above the keyboard and stays tappable. Actual: the keyboard covers about 60% of the button, and taps in that area do nothing.

    Example 4: API and data (4 steps)

    Preconditions: test-environment token issued; the database holds 12,400 orders, 12 of which match the keyword. Environment: https://api-test.example.com / curl 8.x.

  • GET /api/orders/export?month=2026-08 with the header Authorization: Bearer <token>
  • Wait for the response
  • Observe the HTTP status code and the response body
  • Retry with month=2026-08-01~2026-08-07

    • Expected: 200 with an export job ID, or 202 if the job was queued. Actual: 504 (gateway timeout); narrowing the date range returns 200, so the threshold depends on data volume.

    Example 5: Intermittent bug (with probability and timing)

    Preconditions: account has no balance; the test card is attached to the test user. Environment: Chrome 120 / macOS 14 / network throttled to 3G.

  • Open /checkout and fill in the payment details
  • Open DevTools and set the Network panel to 3G throttling
  • Double-click "Confirm payment" quickly (click interval around 300ms)
  • Observe the order list and the payment log

    • Expected: exactly one order created; repeat clicks should be de-duplicated on the client or blocked by API idempotency. Actual: 3 out of 10 attempts created two orders (reproduction conditions: interval <500ms plus network latency >1s). Network panel recording and the request IDs of both POST /api/orders calls are attached.

    How to write up an intermittent bug:

    • Give a probability, not the word "intermittent": "3 out of 10 attempts" is a hundred times more useful.
    • Give the timing or threshold: "<500ms interval", ">1s network latency" — these conditions are often the root-cause clue.
    • Give the evidence type: a screen recording and console logs are the only durable evidence an intermittent bug can carry.

    7 Mistakes That Invalidate Your Steps

  • Starting from "open the homepage": navigation is filler; the first five steps are noise.
  • Multiple actions in one step: "fill the form and submit" — you can't locate the failure.
  • Placeholder descriptions: "enter the correct username and password", when those exact values are the key variable.
  • Missing data preconditions: how many items in the cart, what account type, whether a refund was already issued.
  • Internal jargon: "run the old flow", "use a plan-B account" — external collaborators can't decode it.
  • Expected results smuggled into the steps: "step 3 should show a dialog" — that belongs in its own field.
  • Speculation inside the steps: "step 4 errors out because the cache is stale" — move guesses to notes and mark them "suspected".

    • Pre-Submit Checklist

    • Preconditions written (login state + data state)?
    • The first step is a business action, not "open a browser"?
    • Exactly one action per numbered step?
    • Real values rather than placeholders?
    • Observation noted after the key steps?
    • Expected and actual results kept separate?
    • Intermittent bugs include a probability and timing?

    FAQ

    How many steps should a reproduction write-up have?

    Usually 3–8. Fewer than 3 usually means missing preconditions; more than 8 usually means it can be trimmed — move the navigation into the preconditions and keep only the actions needed to trigger the problem.

    Should the environment go in the steps or in its own field?

    Its own field. Putting it in the steps breaks the reading rhythm and makes it impossible to filter on. If the report format has no environment field (an email, for example), declare it in one line at the top of the steps: "Environment: Chrome 120 / macOS 14 / 1920×1080".

    Should irrelevant actions like "click Back" or "close the dialog" be included?

    Only when they're part of the reproduction conditions. Test it: delete the step — does the bug still occur? If yes, drop it; if no, it has to stay.

    How do I write steps for a bug I can't reproduce myself?

    Write three things honestly: ① the conditions you tried (which attempts succeeded and which failed); ② the strongest evidence you have (recording, console logs, network requests); ③ any correlation you noticed ("only when the network is slow"). Mark it "reproduction conditions unconfirmed" in the title or notes rather than pretending it's deterministic.

    What's the difference between reproduction steps and test cases?

    A test case is a checklist designed in advance — covering happy paths, boundaries and exceptions in pursuit of coverage. Reproduction steps are one path recorded after the fact, aiming only at replaying the problem reliably. The two inform each other, but the goals differ — for test case writing, see test case template with examples.

    Write the Steps Yourself; the Evidence Can Be Automatic

    The steps have to come from the person who clicked — only you know what you did. But the environment and evidence that travel with it can fill themselves in:

    • Screen recording: one-click recording of the current tab with trimming, so even intermittent bugs carry replayable evidence.
    • Diagnostic data: error-level console logs and failed network requests (HTTP ≥ 400) are collected, with sensitive parameters redacted.
    • Automatic technical context: URL, browser, OS, resolution and viewport are written in for you.
    • Annotated screenshots: drag to select an area and add arrows, boxes and text to pin down the failure.
    • Share or sync: generate a share link that opens without registering, or push the report into Feishu Bitable or a generic webhook.

    Further reading

    #steps to reproduce #bug reporting #QA #tutorial
    Share

    Related Articles