QA Acceptance and Regression Checking
Verifying that a shipped change did what was asked, and that it did not break something else.
Analogy Mental model
Tapping every tile after the tiler finishes. The claim that it is done is not evidence; the hollow sound is.
In practice What you actually do
Verify in staging first, then confirm in production on a real device. Re-run the markup validator, re-measure performance, inspect the rendered output, and watch the following week of reporting for anything unusual rather than closing the ticket on the day of deployment.
Where people get burned Pitfalls
The classic case is fixing the canonical tag and losing the language annotations in the same commit. Check what you asked for and check what shares the template, because the second is where regressions live.
This entry was written in English from the Chinese original, not machine-translated. Read the Chinese version →