PR reviews prove bug fixes with a before/after reproduction

STOCKHOLM, 26 August 2026 – A passing test on a bug-fix PR proves very little on its own. The flow may never have hit the bug. QA.tech's review now does what a careful reviewer does: reproduce first, then confirm.

How it works

For a bug-fix pull request, the review agent derives the failure from the fix itself, drives the app into the state that triggers it, and runs the same check against both the base environment and the PR preview. The review comment opens with a Reproduction section showing the before and after result with screenshots. A pass means the behaviour was confirmed and fixed, not that a happy path ran.

The verdict has to be earned

This builds on three changes from the summer. Since 24 June a review can return "unverified" when the agent could not confirm the change. Since 1 July a failure must come with evidence that the diff caused it before it counts against the PR. Since 2 July a test that fails for a fixable reason, an ambiguous step, an overly strict expected result, a missing setup step, a needed scroll or wait, is repaired and rerun before any verdict is posted; real blockers such as a paywall or a missing integration are called out plainly in the review's suggestions.

Dependency updates get the same treatment: the review identifies which changed packages affect runtime behaviour and tests the flows that exercise them, with a core smoke pass as the fallback. Purely build and dev-tooling bumps get a clear "unable to review".

Why it matters

It will not catch everything. What it removes is the green tick that meant nothing: a review that passed because nothing it ran touched the change.