Guide · reproducible results
How to file a QA result someone else can reproduce
First published · Facts checked
Short answer
File one result for one claim: exact URL, build if you have it, steps, expected outcome, actual outcome, evidence, and whether the check passed, failed, was blocked or was not run. Another person should be able to repeat that claim without guessing.
On this page
Context and limits
A QA result is usable when another person can repeat the same claim and see whether they get the same outcome. That applies to a pass, a failure, a blocked check and a check you did not run. A bug template is the form for a failure. This page is the rule for any result you hand to someone else.
Have a site ready to check? Test my site free. Add your URL and review a test plan before starting a run. See a sample report first.
One result, one claim
Write one sentence that can be true or false. “The pricing link on the home page opens /pricing and the plan heading is visible” can be repeated. “The site feels off” cannot. If you have two claims, file two results, even when they showed up in the same session.
Name the person the record is for: a teammate, a client, or the person applying a fix. They were not in the room. Anything you noticed and did not write down is invisible to them.
The fields the next person needs
- Where. Full URL, and the build or commit if you have one. If you do not, write Unknown. Do not invent a build number.
- Start state. Signed out or an approved test role. No passwords in the file. Viewport as CSS pixels if layout matters.
- Steps. Numbered, starting from a named page. One action per step.
- Expected. The observable thing you required, written before you look for an excuse.
- Actual. What happened, including the exact visible text when text is the point.
- Status. Passed, failed, blocked or not run. Use blocked when something stopped you, and not run when you did not try.
- Evidence. A path or link to the screenshot, recording or log you actually have. If you have none, write None.
A failure that needs a fix can use the copyable fields in the bug report template. Do not paste that whole template onto a pass. A pass still needs the claim, the steps and the status, so someone can repeat it later and see if it still holds.
Passes, failures and open checks share one frame
A pass means the claim held on that attempt, on that URL, with those steps. It does not cover a claim you did not write. File the pass with the same where, steps and expected line you would use for a failure. Otherwise a later failure has nothing to compare with.
A blocked result still needs the step you could not take and what stopped you. A not-run result needs the reason it was skipped. Both stay open. Neither is a pass. The post blocked is not passed is the longer version of that rule.
When you file from a Sybqa report, copy the run, the route and the captured steps. Do not rewrite them from memory if the report already has them. The report example shows how those pieces are labeled. Your site’s report is a different run.
Point at evidence instead of retelling it
A screenshot supports what was on screen. It does not, by itself, prove a click landed, a record was saved, or a payment completed. If the claim is about one of those, the evidence has to be about that, or the status stays short of a pass.
Remove secrets, session tokens and personal data before you file. Typed form values do not belong in a chat with a coding tool. Say which approved test data the next person should use, and send the secret values through a channel meant for secrets.
After a fix, repeat the same claim. A new result that changes the URL, the role or the width is a different check. Say what changed. The retest post walks through that comparison. A message that says “fixed” is not a new result.
Common questions
What does another person need to reproduce a QA result?
The URL, the start state, numbered steps, the expected outcome, the actual outcome, the status, and a pointer to any evidence you kept.
Should a passed check use the same record as a failed one?
Yes. Same claim, same steps, status passed. A pass with no steps cannot be repeated when you want to know if it still holds.
Does a screenshot by itself make a result reproducible?
No. The next person also needs the steps and the expected outcome. A screenshot shows one moment. It does not show the path that produced it unless you write that path down.
Sources
Related
Related reading
- Bug report template: steps, evidence and retest status
- How to smoke-test a published website and retest a fix
- What a failed visual check proves and does not prove
- Website QA checklist for a release candidate
- How to write expected results before a website QA run
- How to triage a website QA report before you file bugs
- Test your published Lovable site and send the fix brief back
- How to retest a website fix without writing test code
- Blocked is not passed: how to read open checks in a QA report
Try Sybqa on your site
Explore bugs, UI consistency and user journeys from a reviewed plan. Inspect browser evidence and visual review leads in the report. The free plan gives 10 runs a month without AI review after you sign up. See pricing.
Add your site link here and it will be waiting in the console after you create an account. Then describe one journey to check and review the test plan before any run starts.