Steps to reproduce
Steps to reproduce are the ordered instructions that make a bug appear again on somebody else's machine. They are the part of a bug report that decides whether it can be fixed at all: a defect nobody can reproduce cannot be confirmed, cannot be verified as fixed, and is usually closed without a change.
The longer version
A report has three parts that do different jobs: what happened, what should have happened, and how to make it happen again. The third is the one that determines the report's fate. An engineer who can reproduce a bug can watch it in a debugger and knows immediately when it is gone. An engineer who cannot is reduced to guessing at a cause and then guessing at whether the guess worked.
Steps that work start from a state the reader can also reach. Beginning at a signed-in account with a particular record already open assumes a machine the reader does not have; beginning at the sign-in page and saying which account, which record and which route to it does not. Each step should be one action with one observable result, and the last step should be the moment the wrong thing happens rather than a summary of it.
The clicks are only half of it. Most bugs that resist reproduction are conditional on something the reporter never thought to mention: the browser and its version, the screen size, the account's role and permissions, the data in the record, the network conditions, whether it was a fresh page load or the fifth navigation in a single-page app. That context is what turns steps that work on one machine into steps that work on any machine.
This is why an unreproducible report is not the same as an invalid one. The bug may be entirely real and conditional on something nobody captured. Teams that close these as irreproducible are usually right to when the report carries nothing to investigate, but the cost lands on a user who reported something true and watched it get dismissed; a report with a console error or a failed request on it earns a bounded look at that evidence first.
Common questions
What makes steps to reproduce good?
They start from a state the reader can reach without help, they contain one action per step, and they end at the moment the defect appears rather than at a summary of it. They also record the conditions around the actions: browser and version, viewport, account role and the state of the data involved.
What happens to a bug that cannot be reproduced?
A report nobody can reproduce is usually closed as irreproducible, which is not the same as invalid: the defect may be real and conditional on something nobody captured, such as one account's data or a browser version. A report that carries evidence, a console error or a failed request, gets a bounded investigation from that evidence before anyone closes it. Reopening a closed report needs new evidence rather than a repeat of the original description.
How many steps should a bug report have?
As few as still reproduce the defect. A reporter's path often includes actions that are incidental, and every one of them is another thing the reader has to do before reaching the failure. Trimming the sequence to the shortest one that still fails is the most useful thing a reporter can do after finding the bug.
Are steps to reproduce needed if there is a recording?
A recording shows what happened and removes most of the ambiguity, but the written sequence is still what makes the bug searchable, quotable in a ticket and checkable once a fix exists. The recording is the evidence; the steps are the instruction somebody follows to confirm the defect is gone.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.