Blog · Reports and retests
How to retest a website fix without writing test code
Short answer
After the fix is live, re-run the same check that failed, at the same URL, viewport and starting state. A retest that changes any of those says nothing about the original bug. Keep the failure in history; a passing recheck still needs review.
On this page
You found a bug, your AI builder says it fixed it, and you do not write test code. You still need to know whether the fix worked. The answer is to repeat the exact check that failed, not to click around again. This post explains what “the same check” means, how Sybqa keeps a check you can run again, and how to read the result.
By Sybqa · First published · Updated
A retest repeats one check exactly
A check has five parts. Change any one of them and you are running a different check.
| Part | Example | If it changes |
|---|---|---|
| URL | The published signup page your visitors open | A pass on the preview or on another domain says nothing about the published page. |
| Screen size | A 390 × 844 phone viewport | A bug seen on a phone can still be there when the desktop page looks fine. |
| Starting state | Signed out, empty cart, fresh browser | A signed-in or pre-filled state can skip the broken step. |
| Steps | Open signup, leave the email empty, select Create account | Different steps may never reach the broken code. |
| Expected result | The message “Enter your email” appears under the field | A looser expectation can pass while the bug is still there. |
You do not need test code to keep a check
In Sybqa, the reviewed plan is the test. A run keeps its plan with the target, steps and assertions. After a fix, open the failed run and choose Retest after a fix. Sybqa restores the retained plan for you to review, and nothing runs until you start it.
Without a tool, you can do the same by hand: write the five parts into the bug report before you hand it to your builder, then follow them word for word after the fix. The bug report template has a field for each one.
/demo/shop/ and a fixed copy at /demo/shop-fixed/. Because those are different URLs, a comparison between them is inconclusive by design: it shows a working store, not that the original bug was fixed. To see both runs without running anything, see the recorded retest, which sets its checks beside the run that found the bug.Retest a fix in five steps
- Confirm the fix is live. Open the URL your visitors use and check that the change is there. A builder saying “fixed” is not a deployment.
- Restore the same check. In Sybqa, open the failed run and choose Retest after a fix. By hand, open the steps in your bug report.
- Keep everything equal. Same URL, screen size, starting state, steps and expected result. On a local install that used test credentials, supply them again.
- Read the result for the check that failed. Start the run, then open that check, not only the overall verdict.
- Record both runs. Keep the original run ID and the retest run ID together in the issue.
Sending the finding to a builder first? Test your published Lovable site shows how to copy a fix brief into the builder’s chat and come back for the retest.
How to read the retest result
Sybqa compares the retest with the original failed run and gives each check that failed one of three results:
- Recheck passed (shown as “Recheck passed: review before closing” in the report and the console): the same journey assertions passed on this attempt. Look at the new evidence and decide whether it covers the original bug. An intermittent bug can come back.
- Still failing: the same check failed again, with captured evidence. Send the new evidence back to whoever is fixing it.
- Inconclusive: the two runs cannot be compared. Sybqa says why, for example a changed target, changed plan fields, a different browser engine, or a recheck that was blocked or did not capture evidence.
Only journey checks that end in an explicit assertion, such as an element, text or URL that must appear, and that captured evidence, can be compared this way. AI review leads and crawl findings stay inconclusive until a person checks them.
Keep the failure in history
A passing retest does not erase the original failure. Sybqa links the comparison to the original failed run and counts every attempt: how many passed, failed, were blocked or were inconclusive. A check that failed twice and then passed once is possibly intermittent, not fixed.
Close the issue when a person has looked at the passing evidence and agrees it covers the bug. Then check the pages around the fix separately, because repeating one check is not a regression test. The smoke test guide sets out a small check you can repeat after every publish.
What a retest cannot tell you
- That nearby pages still work. A retest repeats one check.
- Which build answered. A revision label typed into a plan is a declaration, not proof of what was deployed.
- That data was saved or an email was sent. Hosted runs block HTTP writes by default, and a screen shows only what it displayed.
If the retest itself was blocked, the bug is still open. Blocked is not passed explains what to do with a check that could not run.
Common questions
Can I retest a fix on a different URL, such as the preview?
You can run a check there, but it is a different check. Sybqa marks a comparison with a changed target as inconclusive. Retest at the URL where the bug was found.
Does a passing retest mean the bug is fixed?
It means the same assertions passed on that attempt. A person still needs to review the evidence, and the original failure stays in the history.
Do I need to write Playwright tests to retest a fix?
No. In Sybqa the reviewed plan is the saved check, and Retest after a fix restores it. If your team wants a scripted suite it owns, see the Playwright comparison.
Sources
Related
- How to smoke-test a published website and retest a fix
- Test your published Lovable site and send the fix brief back
- Bug report template: steps, evidence and retest status
- Blocked is not passed: how to read open checks in a QA report
- AI exploratory testing: treat every finding as a lead
- What is website QA? A plain definition with examples
- Example run: a planted checkout bug on a demo store
- Example retest: the same checkout after the fix
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.