Bug reproduction
Bug reproduction is making a reported defect happen again on demand. It takes the steps the reporter followed and the conditions they were in, such as the browser, device, account state, data and software version, and reruns them until the failure appears. A defect that can be reproduced can be diagnosed, fixed and then checked against the same recipe.
The longer version
Reproduction is the first thing a developer or tester tries with a new report, and it comes before any reading of code. The written steps to reproduce are the recipe; the reproduction is cooking it. When the failure appears, the investigator has something to observe, debug and measure. When it does not, the report is not wrong so much as incomplete, and the next move is to find which condition the reporter had that the investigator does not.
Conditions matter as much as steps. The same clicks can pass on one browser and fail on another, work for an administrator and break for a member, or fail only on the second visit when a cached script is stale. Reporters rarely know which of these counts, which is why a report that arrives with the environment, the console output and the network calls attached shortens the search. Reduced to its minimum, a reproduction removes every step and setting that is not needed, and the smallest case that still fails is usually where the cause shows.
Conditions can hide a failure completely. A customer reports a blank invoice table, and the investigator follows the steps on their own account and sees rows. The reporter's console shows a 403 from the line-items call, and their account has the viewer role, so the next attempt uses a viewer and the table is empty. The condition was the role, not the steps. Failures that depend on timing or on one particular record may appear once in fifty tries. For those, logging added to the build or a trace captured in the original session shows the failure without waiting for it to recur.
Common questions
What does it mean to reproduce a bug?
To reproduce a bug is to make the failure happen again by following the reported steps under the same conditions. Success means the investigator sees the same wrong result the reporter described, which gives a developer something to debug and a tester something to check the fix against.
Why can't I reproduce a bug a user reported?
The usual cause is a condition the report did not mention. The user may have a different browser, device, account role, data state or software version, or the failure may depend on timing or on the order of earlier actions. Comparing environments and asking for the console output and network calls narrows the gap faster than repeating the same steps.
What should a bug report include to make it reproducible?
A reproducible report names the environment and version, the starting state, the exact steps in order, the expected and the actual result, and any error output. Attaching a screenshot, console log and network activity saves the questions that otherwise delay the first attempt.
What is a minimal reproduction?
A minimal reproduction is the smallest set of steps, data and settings that still triggers the failure. Building one means removing each step and configuration in turn and checking whether the bug survives. The case that remains points at the cause and is easy to attach to a fix or a report to another team.
What do you do with a bug you cannot reproduce?
Keep the report open and add what is missing: logging at the point of failure, a trace captured when it happens, or a request for the reporter's environment. If a second occurrence never arrives, the team can close it as not reproducible with the evidence noted, which keeps the decision reviewable if the failure returns.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.