Visual Testing
Visual Testing Explained: Screenshots, Baselines, and Review
Learn how visual testing compares screenshots against approved baselines, why harmless differences happen, and how to keep visual checks stable and useful.
- Published
- Reading time
- 5 min read
- Difficulty
- Beginner
- Audience
- For Manual tester, QA engineer, Automation tester, Developer
Article overview
What you will learn
- How screenshot comparison works
- What a baseline is and who approves it
- Why harmless differences happen so often
- How to make visual checks stable rather than noisy
- What visual testing cannot tell you
Before you begin
Prerequisites
- Basic familiarity with testing a web interface
Visual testing in plain words
An ordinary automated test can confirm that the Buy button exists and can be clicked. It will happily pass while that button sits behind a banner, overlaps the price, or has slid halfway off the screen on a narrow window. The test asked "is it there?", not "does this look right?"
Visual testing fills that gap by keeping an approved picture of each screen and comparing new screenshots against it — the same way you would notice a picture frame hanging crooked without measuring anything.
Why it matters
Visual breakage is embarrassing in a way logic bugs are not — everyone can see it, including customers and executives. It also spreads: one change to a shared component can quietly damage forty pages, and nobody opens all forty before a release. A visual check on shared components catches that in one run.
Key terms, made simple
| Term | What it means | Everyday comparison |
|---|---|---|
| Snapshot | A screenshot taken by the test | A photo of the shelf before you dust it |
| Baseline | The approved screenshot to compare against | The photo you agreed was correct |
| Diff | The highlighted picture of what changed | The circled differences in a puzzle |
| Threshold / tolerance | How much difference is allowed before failing | Ignoring one grain of dust, not a missing shelf |
| Approve / update baseline | Accepting a change as the new correct picture | Taking a fresh reference photo after redecorating |
| Visual regression | Something that looked right before and does not now | A shelf that has started to sag |
How screenshot comparison works
- Get the page into a known state, with fixed test data.
- Render it in a defined browser, window size, operating system, and font setup.
- Capture the whole page or, better, one focused component.
- Compare the image against the approved baseline.
- Look at the differences and decide: did the product break, or did the design intentionally change?
- Record that decision — approving a new baseline alongside the change that caused it.
Example: a product card
import { test, expect } from '@playwright/test'; test('product card matches its approved layout', async ({ page }) => { await page.goto('/products/example-item'); const card = page.getByRole('article', { name: 'Example item' }); await expect(card).toHaveScreenshot('product-card.png');});This captures one meaningful component rather than an entire page full of unrelated content that will change for other reasons. In a real project, fix the product data, wait for images and fonts to finish loading, and create the baseline in the same environment where comparisons will later run.
Why screenshots differ
- A different browser or operating system draws text slightly differently
- Fonts or images arrived a fraction of a second late
- Animations, blinking cursors, clocks, or rotating banners were mid-motion
- The data changed — a different product name, a new review count
- A different window size, zoom level, language, or dark/light mode
- A genuine, intentional design change
The first five are why visual testing gets abandoned by teams who skip the setup work. Control them and the technique becomes reliable; ignore them and you get a wall of false alarms.
Your first week
- Choose three shared components used across many pages — a header, a card, a form.
- Pin the data those components display so it cannot change between runs.
- Generate baselines in the environment where the tests will actually run, usually CI, not your laptop.
- Run the comparison five times with no code changes. Any failure now is noise to fix, not a bug.
- Agree who reviews and approves a visual change, and where that approval is recorded.
- Only then extend to full-page screenshots of your key screens.
Keeping visual tests stable
- Run comparisons in one controlled environment — usually a container in CI.
- Use fixed data and a deterministic page state.
- Disable or complete animations before capturing.
- Wait for the content that matters instead of a fixed delay.
- Capture focused regions when a full page adds unrelated noise.
- Use tolerances sparingly and know what they might be hiding.
- Commit baseline updates alongside the change that justified them.
What visual testing misses
A screenshot knows nothing about whether the markup is meaningful, whether the page works by keyboard, whether a screen reader announces anything sensible, or whether the wording is understandable. It also cannot distinguish an intended redesign from a defect — only a person can. Treat it as one instrument among several: functional checks, accessibility testing, and human review each answer questions screenshots cannot.
Key takeaways
- Visual tests compare rendered appearance against an approved baseline.
- Controlled environments and fixed data are what make it work at all.
- Focused component screenshots produce clearer failures than whole pages.
- Tolerances hide differences; use them deliberately.
- A human approves every change — and screenshots never replace accessibility or functional testing.
Frequently asked questions
Should every page have a screenshot test?
No. Prioritise shared components, critical journeys, and responsive layouts. Screenshotting everything produces a large, noisy suite that people stop reading.
Can visual tests run on both a laptop and CI?
They can run, but the rendering will differ enough to cause failures. Generate and compare baselines in one consistent environment — usually the same container or CI runner.
Is visual testing the same as design review?
No. Design review asks whether the design is good. Visual testing asks whether the interface still matches what was already approved. You need both.
What is a sensible tolerance setting?
As tight as your environment allows. A high tolerance quietly permits genuine layout breakage, so it is better to fix the source of the noise than to widen the threshold.
References and further reading
- Visual comparisonsPlaywright documentation · Verified 2026-07-19
- Web Content Accessibility GuidelinesW3C Web Accessibility Initiative · Verified 2026-07-19
