A practical guide to baselines that don't rot

The baseline is the most important and least respected artifact in visual testing. Every comparison is only as trustworthy as the image you're comparing against — and yet baselines tend to get updated in a hurry, under pressure, with a bulk 'approve' click at the end of a long day.

Update baselines on purpose

When a design change is approved, re-run the comparison and save the new result as the baseline deliberately. Don't delete the old one in a panic because something went red. A red result is information; treat it as a question, not an annoyance.

Habits that keep baselines honest

• Standardise capture dimensions so a viewport change doesn't masquerade as a regression.
• Group related screens into projects so a baseline refresh is scoped, not global.
• Review test runs within the same sprint — stale results are far harder to trace back to a cause.
• Tie baseline approval to the same review as the design change, so the two never drift apart.

A baseline you approved without looking is just a screenshot of a bug you've agreed to keep.

None of this is heavy process. It's the difference between a suite that gets more trustworthy over time and one that slowly decays until someone proposes deleting it. Spend the small amount of care up front; the baseline pays it back every release.