Home / Knowledge hub / Reproduction steps
Knowledge hub
Reproduction steps
The exact steps another person can follow to see a vulnerability for themselves.
What it means
Reproduction steps are a written recipe that lets someone else make the same flaw happen on their own screen. A good set names the account used, the address visited, the exact request sent, what was expected, and what happened instead.
The test of a good set is simple: could a developer who has never met the tester follow it, in order, and reach the same result? If they need to ask a question or guess a value, the steps are not finished yet.
Why it matters
A report nobody can reproduce gets argued about instead of fixed. Developers lose time guessing, push back with 'works on my machine', and move the ticket down. Clear steps remove the argument, save the reviewer an afternoon of guessing and shorten the time to a fix.
They also decide whether a fix worked. After the change, the same steps are run again. If the flaw no longer appears, you have evidence. If the steps were vague, nobody can tell whether the problem went away or the tester simply did something different.
How it shows up
Good steps include the environment and version, the account or role used and how it was set up, each action in order, the exact request and response, and a screenshot where a person can see the result. Say what data was created so it can be cleaned up. Keep out real customer data.
The common failures are missing preconditions, values that only worked once, and steps that quietly depend on timing or a previous test. The best form is a ready request that can be replayed. See proof of concept and security finding for how steps sit inside a report, and retest for how they are reused.
Questions people ask
Reproduction steps, answered
What should reproduction steps include?
Environment, account, numbered actions, the exact request and response, the expected result and the actual one. Add a screenshot or recording where it helps.
State clearly any setup that must be done first.
How detailed should they be?
Detailed enough that someone unfamiliar with the app can follow them without asking questions. Too short is the common mistake.
Test them on a colleague before sending.
Are reproduction steps the same as a proof of concept?
Close. A proof of concept demonstrates that the flaw can be exploited, often as a script or request. Steps explain how to get there and what to look for.
A good report has both.
Can we get steps from an automated scanner?
Some tools give the request that triggered the result, which is a start. Whether it works is another matter, and many reported items cannot be reproduced.
Check before filing the ticket.
What if we cannot reproduce a finding?
Ask the reporter for the missing detail, check that you are on the same version and data, and try the exact request. If it still fails, record that and close it with reasons.
Do not close it silently.
Sources
Where this comes from
Related
Terms that sit next to this one
Proof of concept
The smallest demonstration that a vulnerability is genuinely real.
Security finding
One confirmed weakness in a report, with the evidence to show it is real.
Retest
Running the test again to confirm that a reported flaw has really been fixed.
Evidence of exploitation
The request, response and screenshot showing a flaw was truly used.
Penetration test report
The document that lists what was found, how, how bad it is and how to fix it.
Can someone else repeat it?
Each finding carries the request, the response, a screenshot where a person can see it and the line of code, so your team can repeat it themselves. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.