How to verify a website bug fix before closing a report

To verify a website bug fix, repeat the reported steps with the same relevant starting conditions, check the expected outcome on the corrected version, and confirm that version is deployed. Test nearby behaviour that the change could affect. Record what passed and what remains untested before closing the report. A source-backed recommendation is a reason to test a change, not proof that the visitor's problem is fixed.

Define what would count as fixed

Turn the report into a checkable statement before reviewing the change. Write down:

• The visitor's starting conditions, such as signed-in state, role, and whether a required field was empty.
• The ordered actions that produced the problem.
• The expected visible result.
• The actual result described in the report.
• The version and environment used for the check.

Use synthetic data rather than copying private customer records into a test. Preserve the relevant shape, such as an empty field or a long name, without preserving the person's values.

For example, a hypothetical report might describe a profile form that shows success but loses the change after reload. A useful acceptance check is not simply that the success message appears. It is that the new value remains after reload. Choose the observable outcome that matters to the visitor.

If the original steps remain unclear, use the guide to what makes a bug reproducible before declaring a pass.

Establish a before-and-after comparison

When it is safe and practical, reproduce the failure on the earlier version in a controlled test environment. Then run the same steps on the proposed correction. This helps distinguish a change that addresses the reported condition from a test that never exercised it.

Do not recreate a destructive failure in production to obtain that comparison. Problems involving money, access, or lost data need an isolated test and an authorized review process.

If you cannot reproduce the earlier failure, say so. You can still record that the corrected version passed particular checks, but that is weaker evidence than a test that fails before the change and passes after it.

For an intermittent problem, one successful attempt does not establish that the underlying condition is gone. Test the suspected timing or sequence, and record the attempts and conditions. The guide to investigating an intermittent website bug explains how to keep those observations honest.

Test the outcome and the nearby paths

Start with the exact reported scenario. Then choose a small set of neighbouring checks based on what changed:

• Does the normal successful path still work?
• Does an empty or boundary input behave as intended?
• Does the page recover from a failed request instead of remaining stuck?
• Can the affected control still be reached and used with a keyboard?
• If the report concerns a narrow viewport, does the relevant action remain visible there?

These are prompts for selecting checks, not a requirement to test every browser and every possible state for each correction. Match the checks to the risk of the change.

Add a focused regression test where practical. A test should assert the behaviour that failed, not merely that the new code executes. Keep manual observations alongside it when an automated check does not cover the visitor's environment.

Verify the version that visitors receive

A local pass does not prove a deployment succeeded. After the normal release process, confirm that the website serves the intended version and perform a safe check of the affected flow.

Distinguish a newly loaded page from a tab opened before deployment. Cached assets or an old tab can make two people test different versions while believing they tested the same website. Do not erase that distinction by recording only the time of the check.

Record the full deployed revision where available. Read how to keep reports mapped to the deployed commit for the difference between an explicit pin and a checked branch head.

Keep a short verification record

A useful closure note can follow this template:

Reported condition: The starting state and actions that failed. Version checked: The corrected revision and test environment. Observed outcome: What happened after the same actions, including a reload if persistence matters. Nearby checks: The related paths tested and their outcomes. Limits: Conditions not reproduced or environments not checked. Decision: Close the report, continue testing, or collect one specific missing observation.

This record separates the investigation's conclusion from your own verification. A plausible cause, an accepted recommendation, a deployed change, and a passed verification are different milestones.

Only use “fixed” in a visitor reply when your checks support it. If evidence is incomplete, describe the change and the checks without claiming more. See how to respond to a website problem report for plain-language follow-up.

Where IssueProbe fits

IssueProbe gives an eligible report a bounded, read-only source investigation. Its result separates the conclusion, evidence citations, unknown facts, recommended action, and draft response. The conclusion can remain unknown. Review the illustrative example report and the guide to reviewing an AI-generated investigation before acting on a recommendation.

IssueProbe does not change source code, run repository scripts, or release a correction. Verification belongs to your own test and release process. You can append an owner note to record your checks without changing the investigation result. You can also save and copy an owner draft response; IssueProbe does not send it to the visitor.