Between January 2018 to December 2019, 47% of developers in a survey conducted by our Percy team stated that they were currently involved in projects involving visual testing or have in the past. Another 24% planned to work on such projects in the future. 54% of survey respondents also cited catching bugs or regressions as a benefit of visual testing.
Despite being a relatively new practice, visual testing has quickly become a critical priority for modern software teams. This rapid adoption is driven by the ever-increasing expectations users place on visual appeal and consistency across devices. Even if an application functions perfectly, flaws in layout, styling, or responsiveness can undermine the user experience and damage brand perception.
To implement an effective visual testing strategy, it’s essential to understand the key concepts and terminology. This guide provides an overview of visual testing and dives deeper into terms every tester should know.
Defining Visual Testing
Visual testing, also called visual UI testing or visual regression testing, is the practice of automatically verifying that application user interfaces appear correctly during development. Tests capture and analyze UI screenshots across browsers and devices to catch visual defects early.
At the core, visual tests check:
- Layout – Interface elements appear in the proper positions
- Styling – Colors, fonts, etc. are rendered correctly
- Responsiveness – UI adapts to all viewports/devices
- Consistency – UI does not unexpectedly change between versions
Identifying these issues is critical, as visual problems seriously degrade user experiences and perceptions of quality. Research shows that users will quickly abandon apps and websites that appear broken, confusing, or inconsistent.
To prevent this, development teams run automated visual tests on every code change to prevent visual defects from ever reaching real users. Changes that introduce visual differences are caught immediately and flagged for review.
Key Terminology
Now that you understand the purpose of visual testing, let’s explore some important terminology:
Visual Bug – Any UI defect related to styling, layout, or responsiveness issues. For example, elements overlapping incorrectly or fonts rendering too small on mobile devices. Fixing visual bugs is the purpose of visual testing.
Visual Diff – The highlighted differences between a baseline and new UI screenshot identified during visual testing. Signals potential visual bugs.
Snapshot – A browser screenshot captured during test execution to compare against later versions for identifying visual diffs.
Baseline Snapshot – The initial “source of truth” UI screenshot used for comparison whenever new snapshots are captured.
Base Build – The older code version that baseline snapshots are captured from for future comparison.
Responsive Diff – A visual diff exposing styling, content, or layout issues appearing only on certain viewports or devices due to responsiveness problems.
Responsive Breakpoints – The layout widths/ranges where responsive design changes occur (i.e. mobile, tablet, desktop). Ensuring UI correctness at each breakpoint is key.
Real-World Examples
To illustrate these concepts, let’s walk through a hypothetical visual testing scenario for a simple login page:
- Bob the developer writes visual test code to login to his company’s mobile app and captures baseline snapshots of the login page from the base build.
- Later, Bob makes UI changes to fix the login button that now appears too small on mobile devices.
- The visual test code runs again on the new build, logging in and capturing fresh snapshots of the updated login screen.
- A visual testing tool like Percy compares the new login screenshots against the original baseline, identifying visual diffs highlighting the button size change.
- However, Percy also discovers a responsive diff: on tablet devices, the button position shifted down, likely due to a CSS bug introduced. This layout problem only appears between mobile and desktop breakpoints.
- Bob reviews the visual diffs and fixes the tablet CSS issue before shipping the improved responsive login page to production.
Without visual testing, Bob would have likely shipped the tablet layout bug to production, frustrating users and damaging his app’s credibility. Automatic visual testing gave Bob the rapid feedback needed to ship high-quality updates fearlessly.
Implementing Visual Testing
Now that you’re familiar with the motivation and terminology behind visual testing, let’s discuss some best practices for building an effective visual testing process:
Choose robust test runner – Use a capable framework like Selenium or Playwright to simulate user actions. Headless browser modes enable fast, reliable test execution.
Integrate with CI/CD – Run visual tests on every commit to prevent defects from ever deploying. Instant feedback accelerates development.
Test across environments – Validate UI correctness on real mobile devices, browsers, and operating systems for confidence. Leverage cloud infrastructure for scale.
Address test flakiness – Monitor for intermittent failures and filter out false positives due to network blips or randomized data.
Prioritize visibility – Consolidated visual diff reporting and annotations make reviews fast and painless for developers.
Expand coverage – Broad visual test coverage beyond happy paths reduces the risk of overlooking edge case defects.
Update baselines wisely – Only promote new snapshots to baseline when approved to prevent masking real visual bugs as code changes.
Follow these guidelines as a starting point when creating visual tests. Monitor effectiveness and continue optimizing over time as visual testing matures across the organization.
Visual testing has quickly become essential for meeting user demand for pixel-perfect and responsive applications. Identifying these key terms is just the first step to mastering visual testing.
For more help launching and scaling visual testing, see our complete guide to visual regression testing or start testing your UI for free with Percy. Reach out via email or Twitter if any other questions come up along the journey!
