Percy, now part of BrowserStack, captures DOM-based snapshots during CI runs and compares them against approved baselines to detect unintended visual changes in web applications. It integrates with Cypress, Playwright, Selenium, and Storybook through a dedicated SDK, uploads snapshots to Percy's cloud rendering service, and surfaces diffs in a browser-based review interface. TestInspector approaches visual regression differently: SSIM-based screenshot comparison is built directly into the test runner as an assertion type, runs alongside functional test steps without any SDK or CI upload step, and requires no separate tooling to configure.

Teams choosing between them are usually choosing between two different philosophies about where visual testing belongs in the workflow. Percy is designed to layer onto an existing code-first test suite. TestInspector handles visual and functional assertions together, without a code-first dependency. This comparison covers how each tool captures and compares visual state, what the setup and maintenance burden looks like in practice, and which team structures get more value from each option. For context on TestInspector's broader capabilities, see the TestInspector product page. For teams evaluating whether no-code or code-first automation fits their situation, see Astaqc's manual vs. automated testing guide and test automation services page.

How Percy Captures and Compares Visual State

Percy takes a DOM snapshot—the serialized HTML, CSS, and associated assets at a specific point in a test's execution—and uploads it to Percy's cloud rendering service. The cloud service renders the snapshot in a controlled environment and compares it pixel-by-pixel against the previously approved baseline for that test. Differences are highlighted in a side-by-side review interface where a reviewer approves or rejects the diff. Once approved, the new snapshot becomes the baseline for future runs.

The DOM snapshot approach has a specific advantage over simple screenshot comparison: it re-renders in a consistent environment regardless of where the original test ran, which eliminates rendering variation between local machines and CI environments. This matters for teams where developers run tests locally and CI is expected to catch regressions—without consistent rendering, a visual test may flag false positives from font rendering or anti-aliasing differences between environments.

Percy's SDK is required to take snapshots. For Cypress, this means calling cy.percySnapshot() at the point where visual state should be captured. For Playwright or Selenium, the SDK wraps the existing driver. Snapshot calls upload the current DOM to Percy's API, which requires a Percy API key in the CI environment. The comparison and diff review happen in Percy's web interface, decoupled from the test run itself. A test run can complete as passing or failing based on functional assertions while Percy diffs wait for human review in the Percy dashboard.

For visual diffs to block a build, Percy must be configured to report results back to the CI status check. Without that configuration, visual diffs accumulate in the Percy dashboard without affecting build status. The review cadence—who reviews diffs, how often, and what constitutes an acceptable vs. unacceptable change—requires explicit team agreement to function reliably over time.

How TestInspector's Visual Regression Works

TestInspector's visual regression is built into the test step model as an assertion type, not a separate SDK call or upload step. When a test includes a visual comparison step, TestInspector takes a full-page or element-level screenshot during the run, computes an SSIM (Structural Similarity Index Measure) score against the stored baseline, and reports the comparison result as a pass or fail inline with the other test assertions. SSIM measures perceptual similarity rather than pixel-perfect equality, which means minor rendering variation—subpixel font differences, slight anti-aliasing changes—does not automatically produce a failure.

Baselines are approved through TestInspector's interface. On the first run, the screenshot becomes the candidate baseline. Once approved, subsequent runs compare against it. When an intentional UI change updates the visual state, the new screenshot is reviewed and approved in the same interface, replacing the previous baseline. This workflow does not require any code change or external service interaction.

Crop and exclusion selectors allow specific regions of the screenshot to be excluded from comparison. This handles elements with dynamic content—a timestamp, a live counter, an ad slot—where the content changes between runs but the surrounding layout is stable. Rather than suppressing the entire visual assertion or accepting permanent diff noise, exclusion selectors preserve comparison for stable regions while ignoring expected variation in dynamic ones. Configuring this in other screenshot-based comparison tools typically requires manual CSS overrides or test logic; TestInspector exposes it through the step editor.

Visual regression in TestInspector runs as part of a broader functional test. A test that checks login, navigates to a dashboard, and asserts on field visibility can include a visual comparison at any point in that sequence. The visual assertion appears in the same run output as functional assertions, with the same real-time WebSocket streaming that shows step results as the test executes. When both functional and visual assertions are in the same run, failures surface together in the same log, which simplifies the review and routing process for teams that route all test failures to the same bug queue.

Setup, Maintenance, and Infrastructure Requirements

The setup difference between the two tools is substantial for teams without an existing code-first test suite. Percy requires a Cypress, Playwright, or Selenium suite to integrate into. The Percy SDK adds a package dependency, the CI configuration needs a Percy API key, and snapshot calls need to be added at specific points in existing test code. For teams already using Playwright or Cypress, this is a straightforward addition—typically a few hours of work. For teams without a code-first framework, Percy is not usable without first building one.

TestInspector's visual regression requires no prior framework. A tester adds a visual comparison step through the step editor, runs the test once to generate the candidate baseline screenshot, approves it, and subsequent runs include the visual assertion automatically. The first visual test can be configured in the same session as the first functional test, with no dependency setup or CI configuration required beyond what functional testing already needs.

Maintenance burden also differs in practice. Percy's DOM snapshot approach reduces false positives from rendering environment inconsistencies, but the review cadence still requires team coordination. When UI changes intentionally affect many components, Percy diffs accumulate and require bulk approval decisions. TestInspector's inline results integrate with the functional test review cycle, which simplifies the process for teams that already have a functional test review cadence but adds visual review volume to that same workflow.

Where Each Tool Produces Better Results in Practice

Percy produces better results for teams with component-level visual testing requirements. Its Storybook integration allows individual UI components to be visually tested in isolation, which is valuable for frontend teams using component-driven development. When a change to a button component cascades visual changes to every page that uses it, Percy's component-level snapshots can catch the regression at the component level rather than requiring separate page-level tests for each affected page. This is a use case TestInspector does not cover—TestInspector tests pages and elements in the context of a running application state, not isolated component renders.

Percy also produces better results for teams that already have mature Playwright or Cypress suites and want to add visual coverage without restructuring. Adding percySnapshot() calls at existing checkpoints in an existing test suite is lower friction than migrating to a different runner. For teams where the visual testing requirement emerged after a functional test suite was already built, Percy integrates into the existing structure with a small addition rather than requiring a parallel toolchain.

TestInspector produces better results for teams whose visual and functional testing is owned by people who do not write test code. For QA analysts, product owners, or teams that rely on a no-code interface for all their test automation, Percy is not a practical option because it requires a code-first framework. TestInspector makes visual regression accessible to teams that would otherwise skip it entirely—either because they lack code-first framework expertise or because the overhead of maintaining a code-first framework is not justified by the team's test volume.

TestInspector also produces better results for teams that want visual and functional failures to surface in the same place. Percy's separate dashboard works well for teams with a dedicated visual review process, but for teams that review all results in a single interface and route failures to the same bug queue, having visual and functional failures in separate systems adds coordination overhead. For smaller QA teams where a single person reviews all test results, context-switching between a test runner output and the Percy dashboard is a meaningful friction in daily review workflows.

For teams evaluating embedded QA coverage, Astaqc's QA team service covers both visual and functional regression testing. See the software testing services page for full details, and the outsourcing QA guide for when to use embedded coverage versus building internal capacity.

Frequently Asked Questions

Does TestInspector's SSIM comparison handle responsive layout testing at different viewport widths?

Yes. TestInspector supports configurable viewport sizes, and visual comparison steps capture the screenshot at the test's configured viewport. For responsive layout coverage, the same test suite can be run at multiple viewport widths with separate baselines approved for each configuration. A layout change that only affects the mobile breakpoint does not invalidate the desktop baseline. Setting up viewport-specific test configurations is handled in the TestInspector test settings and does not require additional tooling.

Can Percy be used in local development, outside of CI?

Percy can run locally using the same SDK integration and API key that CI requires. The comparison results still appear in the Percy dashboard rather than inline in the terminal, so the feedback loop requires opening the Percy web interface rather than reading terminal output. Percy is primarily designed for CI use, where snapshots accumulate from multiple developers' work and comparisons against a shared baseline catch regressions before merge. For local development visual checks, Percy works but requires an active Percy dashboard session to review results.

What is the practical difference between SSIM comparison and pixel-diff comparison?

Pixel-diff comparison reports a failure for any pixel that differs between the current screenshot and the baseline, including differences caused by rendering variation rather than actual UI changes. SSIM computes a perceptual similarity score that weights luminance, contrast, and structure, which means small rendering variations—subpixel anti-aliasing, minor font hinting differences—are unlikely to produce a failure unless they are perceptually significant. SSIM comparison typically produces fewer false positives for tests that run in varied environments, while pixel-diff comparison is more sensitive to any change and requires a consistent rendering environment to avoid noise.

Can TestInspector and Percy be used together on the same project?

Yes, but they cover different parts of the test surface. TestInspector handles the no-code functional and visual tests authored in TestInspector's interface. Percy handles visual snapshots from Playwright, Cypress, or Selenium tests that exist in the codebase. Teams with a mixed test environment—some code-first tests from developers, some no-code tests from QA—sometimes run both tools in parallel. The practical question is whether maintaining two visual testing review surfaces adds process value or creates confusion about where the authoritative visual baseline lives.

Does Percy support accessibility checks alongside visual comparison?

Percy does not include accessibility assertions—it focuses on visual diff detection. For accessibility testing alongside visual regression, teams typically combine Percy with a separate axe-core integration available as a Cypress or Playwright plugin. TestInspector's accessibility assertions use axe-core with configurable severity levels, which means a single TestInspector test can include functional assertions, visual comparison, and accessibility validation in one run. Teams that want all three assertion types covered by a single tool typically find TestInspector's integrated approach more practical than managing Percy, a separate axe-core plugin, and functional assertions as three separate toolchains.

How long does it take to get meaningful visual regression coverage with TestInspector?

The first visual regression test can be created and have an approved baseline within a single working session. For a typical application with 10–20 key user flows, adding a visual comparison step to each flow and approving the initial baselines can be completed in one to two days. After that, any visual change to those flows produces a comparison result in the run output. The initial baseline approval session is the main setup investment—ongoing maintenance is limited to re-approving baselines after intentional UI changes, which follows the same review process as functional test maintenance.