How to reproduce a bug from a vague user report

Most user reports arrive incomplete. The visitor noticed a result, not a cause, and described the result in ordinary words. A report that says the checkout is broken is still useful. It is a starting point that needs a method, not a better reporter.

Reproduction is that method. A bug you can reproduce is a bug you can fix, test, and prove fixed. A bug you cannot reproduce stays open, consumes attention, and returns.

Why can a report be true and still not reproduce?

A visitor reports what they saw. You try the same action and see the correct result. Both observations can be accurate at once, because a website behaves differently across conditions the visitor never mentions.

Common differences include:

• Account state. A new account, an unverified email, an expired card, or an empty cart follows a different path.
• Data shape. A long name, an unusual character, a missing optional field, or a very large record.
• Timing. A slow network, a double submit, or an action taken before a page finished loading.
• Entry path. Arriving from a saved link or a back navigation instead of the normal flow.
• Build. The visitor loaded an older deployment, or a cached asset from one.

You are not looking for the visitor's mistake. You are looking for the condition that separates their session from yours.

Which questions recover the missing context?

Ask a small number of ordered questions. Each one should narrow the search rather than collect general detail. Three or four specific questions produce better answers than a long form, because a long form is often abandoned.

1. What exactly did you select, and on which page? This converts a feature name into an action and a location.
2. What did you expect, and what appeared instead? This separates a defect from a misunderstanding, and it captures error text.
3. Did it happen every time, or once? This separates a consistent rule from a timing or data condition.
4. What did you do immediately before? This recovers the entry path, which the visitor rarely thinks to mention.

Ask for observations, never for private values. You do not need a password, a card number, or a customer record to reproduce a defect. If you need to identify the session, an order reference or an approximate time is enough.

How do you turn answers into a reproduction attempt?

Write the steps down before you run them. An unwritten attempt is hard to repeat and impossible to hand to someone else.

A workable attempt has four parts:

• Preconditions. The account type, the starting data, and the entry point.
• Steps. The exact ordered actions, one action per line.
• Expected result. What should happen.
• Actual result. What happened when you ran it.

Then change one variable at a time. If the normal path works, try the reported account state. If that works, try the reported data shape. If that works, try the reported timing. Changing two variables at once tells you that something matters, but not which thing.

Keep a short log of what you tried and what happened, including the attempts that failed to reproduce. A failed attempt is real evidence: it rules out a condition, and it stops the next person from repeating the same work.

What if it still will not reproduce?

Stop and record the state honestly rather than guessing at a cause. An unreproduced bug is not a closed bug, and it is not an invalid report either.

Useful actions at this point:

• Write the conditions you eliminated, so the next attempt starts further along.
• Check whether the reported behaviour matches an older deployment.
• Look for supporting signals from the session, such as a failed request or a console error, that confirm something did fail even though you cannot yet trigger it.
• Ask the reporter one narrow follow-up question, chosen from what your attempts ruled out.

Recording "not yet reproduced, ruled out A and B" is far more valuable than recording a confident cause you cannot demonstrate. A wrong cause sends the fix to the wrong place and leaves the real defect in production.

Which context should the report carry from the start?

The fastest reproduction is the one that needs no follow-up. That happens when the report already carries the observable context of the session: the page path, the visible error text, the approximate time, whether a request failed, and whether the browser logged an error.

That context has to be collected safely. Session recordings and broad capture tools solve the context problem by collecting far more than a defect requires, including values that belong to your visitors. A metadata-only approach records that a field or cookie exists and how large it is, never what it contains, which is enough to compare a session against the source without holding private data.

IssueProbe collects that context at the moment a visitor reports a problem through a small widget, in English, Portuguese, or Spanish. Browser state stays metadata only, screenshots require a visible capture action and explicit consent, and each report can start one read-only investigation against your repository at the deployed commit. The result cites specific source locations, or says the cause is unknown when the evidence does not support a conclusion. A human reviews it before anything reaches the visitor.

Continue with what makes a bug reproducible and the website problem report guide. See the example report for how evidence, conclusion, and unknown facts stay separate.