DEV Community: Delta-QA

Storybook Visual Testing Without Chromatic: Alternatives for Testing Your Components Visually

Delta-QA — Sat, 09 May 2026 10:17:56 +0000

Storybook Visual Testing Without Chromatic: Testing Your Components Without Vendor Lock-In

Visual testing is an automated verification method that compares screenshots of an interface — or an isolated component — against reference images to detect any unintended visual regression. If you need a simpler way to compare HTML output visually without a full pipeline, an online visual comparator can help.

If you use Storybook, you've probably heard of Chromatic. It's the visual testing tool built by the Storybook team itself, so deeply integrated into the ecosystem that you might think it's the only option available. It's not. And believing otherwise is a trap too many teams fall into.

This article explores why relying on a single vendor for visual testing your Storybook components is a risky strategy, what alternatives actually exist, and how to choose the approach that fits your context.

Why Storybook and Visual Testing Go Hand in Hand

Storybook has transformed the way front-end teams build and document their components. Each component lives in isolation, with its variants, states, and edge cases. It's a living catalog of your design system.

But a catalog without automated verification is a museum no one's watching. One developer changes a color token in the global theme. Another adjusts a padding to fix a bug on a page. A third updates a CSS dependency. None of these changes break a unit test. None of them fail an integration test. But visually, three components are now broken.

Visual testing fills that gap. It captures the actual appearance of each component in Storybook and detects deviations from an approved reference. It's the safety net your functional tests don't provide.

Chromatic: What It Does Well, and the Problem

Let's be honest: Chromatic is a good product. The Storybook integration is seamless — makes sense, since it's the same team. The review workflow is well designed. Change detection is smart.

So, what's the problem?

Vendor lock-in is real

When your entire visual testing pipeline relies on a single cloud service, you're handing it considerable power over your delivery workflow. If Chromatic changes its pricing — which happens regularly in SaaS — you don't have a plan B ready to deploy. If the service goes down, your merge requests wait. If the API evolves and breaks your integration, your CI grinds to a halt.

This isn't paranoia. It's basic risk management.

Snapshot-based pricing is a ticking time bomb

Chromatic charges per snapshot. Early on, with 50 components and 3 variants each, the bill is reasonable. But a design system grows. Variants multiply. Themes get added. A year later, you have 400 stories and the bill has multiplied eightfold. At that point, reducing the number of snapshots means reducing test coverage — exactly the opposite of what you want.

Your test data leaves your infrastructure

For teams subject to compliance constraints (healthcare, finance, government), sending interface screenshots to a third-party cloud service isn't trivial. Even if screenshots don't theoretically contain sensitive data, security policies don't always make that distinction.

Alternatives to Chromatic for Storybook Visual Testing

Percy (BrowserStack)

Percy is the most established direct competitor. Its approach: you capture snapshots of your Storybook stories, Percy renders them in real browsers in the cloud, and you review differences in a dashboard.

What works. Percy handles cross-browser natively. You test your components in Chrome, Firefox, Safari without configuring anything locally. The review dashboard is mature and the approval workflow is solid.

What's problematic. You're leaving one cloud vendor for another. Pricing is also snapshot-based. And the Storybook integration, while functional, isn't as native as Chromatic's — understandably, Percy wasn't designed specifically for Storybook.

Percy makes sense if your primary need is cross-browser visual testing and you're comfortable with a paid cloud model. But it doesn't solve the fundamental vendor dependency problem.

Playwright with toHaveScreenshot()

Playwright natively includes screenshot comparison. With some configuration, you can use it to visually capture and compare your Storybook stories.

What works. Everything runs locally or in your own CI. No third-party cloud service. No per-snapshot billing. Baselines live in your repo, under your full control. And Playwright is maintained by Microsoft — longevity isn't a concern.

What's problematic. Setup takes work. You need to write the logic that opens each story in a headless browser, takes a screenshot, and compares it. For the exact technical configuration, ask your favorite AI copilot — it'll happily generate a Playwright/Storybook script while you grab a coffee. But you'll be maintaining that code. False positives from pixel-by-pixel comparison will require tuning. And you don't get a review dashboard: when a test fails, you're opening PNG files locally to figure out what changed.

Playwright is the solid technical choice for teams with in-house expertise who want zero external dependencies. But it's a maintenance investment.

BackstopJS

BackstopJS is an open-source tool dedicated to visual regression. It can target URLs — including your locally served Storybook stories.

What works. It's free, open source, and the generated HTML report is more readable than a folder of diff files. The JSON scenario configuration is straightforward.

What's problematic. The project has gone through periods of intermittent maintenance. The Storybook integration isn't direct — you need to point BackstopJS at the individual URLs of each story. For a precise configuration, your favorite AI assistant — the one that secretly dreams of becoming a front-end developer — will whip up the config in no time. But at the scale of a substantial design system, scenario management becomes verbose.

Delta-QA: The No-Code Approach

Delta-QA takes a different angle. No scripts to write. No SDK to integrate into your tests. You point the tool at your served Storybook stories (locally or in CI), and Delta-QA handles capturing, comparing, and presenting differences in a dedicated review interface.

What changes. Visual testing of your Storybook components no longer depends on your test stack. Your QA team can configure and maintain visual coverage without touching test code. Designers can participate in the review workflow — they see visual differences without needing to understand a test report.

What's different from Chromatic. Delta-QA runs wherever you decide. No per-snapshot billing. No dependency on a cloud service you don't control. Your captures stay in your infrastructure.

How to Choose: The Decision Grid

Rather than pretending one solution fits all — that would be dishonest — here are the questions to ask yourself.

Do you have data sovereignty constraints? If yes, eliminate Chromatic and Percy. That leaves Playwright, BackstopJS, and Delta-QA.

Does your team have the skills to maintain visual test scripts? If not, eliminate Playwright and BackstopJS. Delta-QA's no-code approach or Chromatic/Percy's managed model are better suited.

Is your design system actively growing? If yes, watch out for per-snapshot pricing. What costs $50 per month today could cost $500 in a year.

How many browsers do you need to cover? If cross-browser is critical, Percy has a native advantage. For others, headless Chrome is often enough to catch visual regressions.

Do you want to involve non-developers in reviews? If your designers or QA team need to validate visual changes, a tool with an accessible review interface (Delta-QA, Chromatic, Percy) will be preferable to a folder of PNG files in Git.

The Hidden Risk: Tooling Monoculture

Beyond tool selection, there's a more fundamental principle that many teams overlook: don't put all your tests in one vendor basket.

If your CI, functional tests, visual tests, and monitoring all depend on a single ecosystem, a single business decision from that vendor can paralyze your entire pipeline. That's true for Chromatic, and it's true for any tool.

Resilience in software engineering comes through diversification. You don't host your database and application on the same physical machine. Apply the same logic to your testing toolchain.

Migrating from Chromatic: Where to Start

If you're currently on Chromatic and considering an alternative, don't do a big bang. Take it step by step.

Step 1: Identify your critical stories. Not all of them. The 20% that cover 80% of the components visible to your users.

Step 2: Set up the alternative in parallel. Run Delta-QA (or Playwright, or the tool of your choice) on those critical stories alongside Chromatic. Compare results over two to three sprints.

Step 3: Expand gradually. Once confidence is established, extend coverage and reduce your Chromatic usage proportionally.

Step 4: Cut the cord. When alternative coverage reaches a satisfactory level, deactivate Chromatic.

This approach takes time. But it avoids the nightmare scenario where you discover the limitations of your new tool in production.

FAQ

Is Storybook visual testing really necessary if we have unit tests?

Yes. Unit tests verify that your component works — that it accepts the right props, renders the correct content, and responds to events. Visual testing verifies that it looks the way it should. A component can pass all its unit tests and have a completely broken layout. These are two complementary dimensions.

Can you use Playwright to visually test Storybook without Chromatic?

Absolutely. Playwright can navigate to each story individually and compare screenshots. The effort lies in setup and maintenance: you need to write the code that iterates over your stories, manage baselines, and handle false positives. It's doable but it's an engineering time investment.

Does Delta-QA work with Storybook directly?

Yes. Delta-QA can target any served URL, including individual Storybook stories. You don't need to modify your Storybook configuration or install a plugin. As long as Storybook is accessible (locally or via a CI deployment), Delta-QA can capture and compare your components.

Is pixel-by-pixel comparison reliable for Storybook components?

It's reliable if your rendering environment is perfectly stable — same OS, same browser, same resolution, same fonts. In practice, achieving that stability between a developer's machine and a CI runner takes work. Perceptual approaches (which tolerate minor rendering differences) or tools that manage this stability for you significantly reduce false positives.

How much does Storybook visual testing cost if you leave Chromatic?

It depends on the alternative. Playwright and BackstopJS are free (open source) but cost engineering time. Percy charges per snapshot like Chromatic. Delta-QA offers a different model that doesn't penalize you for design system growth. Do the math with your actual number of stories and variants.

Is it possible to combine multiple visual testing tools on the same project?

Not only is it possible, but it's sometimes recommended. You could use Playwright for critical visual tests in your CI pipeline and Delta-QA for collaborative review with your design team. Diversification reduces your dependency risk and lets you leverage each tool's strengths.

Conclusion

Storybook visual testing is essential for any team maintaining a serious design system. But the tool you choose to do it has implications far beyond the technical. It affects your budget, your autonomy, and the resilience of your delivery pipeline.

Chromatic is a good tool. It's not the only one. And in a context where flexibility and independence are strategic advantages, exploring alternatives isn't a luxury — it's prudence.

If you're looking for a no-code approach, without vendor lock-in, that works with Storybook as well as any web application, Delta-QA deserves your attention.

We build Delta-QA, a visual regression testing tool. Always open to feedback from the community!

Playwright and MCP (Model Context Protocol): Revolution or Mirage for Visual Testing?

Delta-QA — Fri, 01 May 2026 08:00:13 +0000

Playwright and MCP (Model Context Protocol): Revolution or Mirage for Visual Testing?

The Model Context Protocol (MCP) is an open protocol, initiated by Anthropic in late 2024, that standardizes how AI models interact with external tools — allowing an LLM to perform concrete actions such as navigating a browser, querying a database, or running automated tests.

Since Microsoft published the Playwright MCP server in early 2025, the testing world has been buzzing with one refrain: "AI will write our tests for us." The demos are impressive. The promises are enticing. And the reality is — as always — more nuanced.

This guide takes stock of what MCP really is, how Playwright integrates with it, what it concretely changes for testing in 2026, and above all: why this undeniable advancement does not solve the fundamental problem of visual testing.

Our position: MCP is a genuine advancement for automation. But if you rely on an LLM to detect that a button has changed color, you are confusing intelligence with precision.

What Exactly Is MCP?

Before MCP, connecting an AI model to an external tool was a craft endeavor. Every integration required custom development. You wanted your LLM to query your database? Custom development. Navigate the web? Another custom development. Run your Playwright tests? Yet another.

MCP solves this by proposing a standardized protocol — a sort of USB-C for artificial intelligence. An MCP server exposes "tools" that any MCP client (Claude, Cursor, VS Code, or your own application) can call uniformly.

The protocol rests on three key concepts:

Tools: actions the LLM can execute. For example, "take a screenshot," "click a button," "fill out a form."

Resources: data the LLM can consult. For example, the accessibility tree of a page, the contents of a test file, the result of a query.

Prompts: predefined interaction templates that guide the LLM in using the tools.

In short, MCP transforms LLMs from "brains locked in a box" into agents capable of acting on the real world. And that is precisely what makes the Playwright integration so compelling.

How Playwright Integrates with MCP

The Playwright MCP server, developed by the Microsoft team, exposes browser capabilities as MCP tools. In practice, an LLM connected to this server can:

Navigate to any URL
Interact with the page (click, type, select, scroll)
Read page content (text, attributes, accessibility structure)
Take screenshots of the page
Execute JavaScript in the browser context

The approach is elegant: rather than asking the LLM to generate Playwright code you then execute, the LLM controls the browser directly in real time. It sees the page (via the accessibility tree or a screenshot), decides what to do, and acts.

This is a paradigm shift. Before: "LLM, write me a test." After: "LLM, test this page."

What MCP Concretely Changes for Testing in 2026

Let's be fair: MCP brings real and significant advances.

Test Generation Becomes Conversational

Gone are the days when writing an E2E test required knowing the Playwright API inside out. You can now describe a scenario in natural language — "Verify that the user can sign up with a valid email, receive a confirmation, and access their dashboard" — and the LLM, via MCP, navigates your application, executes the journey, and reports results.

For test prototyping and exploration, this is a considerable productivity boost.

Debugging Becomes Assisted

When a test fails, the LLM can inspect the page, analyze the DOM state, compare it with expected behavior, and propose a diagnosis. It's like having a pair-programmer who never sleeps and has read all the documentation — even if it occasionally "hallucinates" with the same confidence as a senior consultant billing by the day.

Accessibility Testing Advances

The Playwright MCP server relies on the browser's accessibility tree. The LLM thus has a native view of ARIA roles, labels, and navigation hierarchy. This is fertile ground for smarter and more comprehensive accessibility tests.

Test Maintenance Becomes Simpler

A CSS selector that breaks because a developer renamed a class? The LLM can potentially find the right element by semantic context rather than strict selector. This makes tests more resilient to implementation changes.

The Fundamental Problem: Probabilistic AI vs. Deterministic Testing

Now for the cold shower. Because it needs to be taken.

An LLM is a probabilistic system. It predicts the most likely token at each step. This is what makes it incredibly powerful for understanding language, generating content, and reasoning about complex problems. But it is also what makes it fundamentally unsuited for visual regression detection.

Here's why.

Visual Regression Testing Demands Pixel-Level Precision

When you perform a visual regression test, you compare two screenshots — before and after a change — and detect differences. A margin shifting from 16px to 14px. A color sliding from #336699 to #336689. A font weight going from 500 to 400.

These differences are subtle, deterministic, and measurable. An image comparison algorithm detects them with 100% accuracy. An LLM will tell you "the page looks fine" or "I don't see any major differences." That's the difference between a thermometer and someone touching your forehead.

Reproducibility Is Not Guaranteed

Run the same MCP prompt twice in a row. You won't necessarily get the same navigation path, the same clicks, the same results. An LLM is stochastic by nature. A regression test, by definition, must be reproducible. If your test yields different results on every run, it's not a test — it's an opinion poll.

Hallucinations Are a Real Risk

An LLM can confidently assert that a page "has no visual differences" when an entire panel has disappeared. It can also flag a "visual bug" that doesn't exist. In a QA context where trust in results is fundamental, this level of uncertainty is unacceptable.

Imagine explaining to your client that you missed a visual bug in production because your AI "thought" everything was fine. AI has many talents — but it doesn't yet have the talent for delivering convincing excuses in a meeting.

The Right Approach: MCP as a Complement, Not a Replacement

Our position is clear: use MCP for what it does well, and deterministic tools for what they do better.

MCP excels at test generation, exploration, assisted debugging, and maintenance. It's a remarkable productivity accelerator for developers.

But for visual regression detection, you need a tool that:

Compares images in a deterministic way, not probabilistic
Produces results that are 100% reproducible
Detects 1-pixel differences with certainty
Never "hallucinates" a result
Works without human judgment intervention

This is exactly the purpose of dedicated visual regression testing tools. And this is why, even in a world where MCP makes AI ubiquitous in testing, these tools remain indispensable.

MCP and Playwright in Practice: What Works and What Doesn't

What Works Very Well

Exploring new pages and creating initial automated tests. You give the LLM a URL, it navigates, identifies interactive elements, and proposes a test flow. In 5 minutes, you have a test skeleton that would have taken 30 minutes to write manually.

Fixing broken tests. When a Playwright test fails because of a DOM change, the LLM can analyze the new DOM and propose an updated selector. That's a real time saver.

What Still Falls Short

Managing complex authentication (OAuth, 2FA) remains cumbersome. The LLM struggles with multi-step workflows involving external redirects.

Environments with dynamic data pose problems. The LLM doesn't always distinguish an expected change (today's date) from an unexpected one (a price that changed).

And of course, visual regression detection. The LLM can take screenshots, but it cannot compare them with the required rigor. It's like asking a poet to do accounting — the talent is there, but not for this job.

The Future: Convergence or Coexistence?

Our prediction for 2026-2027: we're heading toward intelligent coexistence.

Tomorrow's test pipelines will combine:

MCP for test generation, exploration, and maintenance
Classic E2E tests (Playwright, Cypress) for deterministic functional verification
Dedicated visual testing tools for visual regression detection with absolute precision

Teams that try to do everything with AI will end up with flaky tests and visual bugs in production. Those that combine approaches will get the best of both worlds.

And the most mature teams will be those that make visual testing accessible to everyone — not just developers who master MCP and Playwright. Because visual QA shouldn't be reserved for those who know how to configure an MCP server.

FAQ

Will MCP Replace Traditional Automated Tests?

No. MCP is an accelerator, not a replacement. It makes test creation and maintenance easier, but the tests themselves must remain deterministic and reproducible. A test driven solely by an LLM via MCP is not reliable enough for a regression suite in CI/CD.

Do You Need AI Skills to Use MCP with Playwright?

Not specifically. If you know how to use a tool like Claude, Cursor, or VS Code with an AI assistant, you can use MCP. The initial setup of the Playwright MCP server requires some technical knowledge, but day-to-day usage is in natural language.

Can MCP Detect Visual Bugs?

The LLM can see a page (via screenshot) and identify obvious anomalies — text overflow, a missing image. But it cannot detect subtle differences (2px offset, a hue shift) with the reliability of a deterministic image comparison algorithm. For visual regression testing, stick with dedicated tools.

Which AI Models Support MCP with Playwright?

MCP is an open protocol. Claude (Anthropic), GPT-4 (via compatible clients), Gemini (Google), and other models can connect to the Playwright MCP server. Result quality varies by model — the most recent and capable models yield better results.

Is MCP Free?

The MCP protocol itself is open source and free. The Playwright MCP server is free. However, using the LLMs (Claude, GPT-4) that connect to MCP is paid according to the provider. You should therefore budget for API calls if you use MCP intensively.

Does Delta-QA Use MCP?

Delta-QA takes a different and complementary approach. Rather than relying on a probabilistic LLM to detect visual regressions, Delta-QA uses a deterministic 5-pass algorithm that analyzes the actual CSS structure. Zero hallucination, 100% reproducible results. MCP is powerful for generating tests, Delta-QA is precise for detecting visual anomalies.

Conclusion

MCP and the Playwright integration mark a genuine advancement for test automation. No longer do you need to master the Playwright API inside out to explore, prototype, and maintain tests. That's a real gain.

But don't fall into the trap of technological enthusiasm. An LLM controlling a browser does not replace a deterministic visual regression testing tool. Precision, reproducibility, and reliability are non-negotiable when it comes to detecting what your users see.

The right strategy: use MCP to move faster, and a dedicated visual testing tool to see accurately.

We build Delta-QA, a visual regression testing tool. Always open to feedback from the community!

What Is Regression Testing? The Definitive Guide (2026)

Delta-QA — Thu, 30 Apr 2026 08:00:32 +0000

What Is Regression Testing? The Definitive Guide (2026)

Regression testing is the systematic verification that a change made to software — a bug fix, a new feature, or a dependency update — has not introduced defects in parts of the system that previously worked.

You just shipped a feature. The client is happy. The team celebrates. And then, forty-eight hours later, support blows up: the payment form no longer works. Nobody touched it. But the code you added elsewhere broke everything, silently.

This scenario is not hypothetical. It's the daily reality of thousands of development teams. And it's exactly what regression testing is supposed to prevent.

This guide covers everything you need to know: the definition, the different types, the ideal time to run it, automation strategies — and most importantly, the type of regression that almost everyone ignores even though it's the most visible to your users.

Why regression testing is non-negotiable

Let's be direct: if you're not doing regression testing, you're playing Russian roulette with every deployment.

Modern software is not a monolithic block. It's a tangle of dependencies, modules, third-party libraries, and configurations that interact in often unpredictable ways. Changing one line in a module can trigger a butterfly effect three layers away.

The numbers speak for themselves. According to the Consortium for Information & Software Quality (CISQ) 2022 report, the cost of software defects in the United States amounts to $2.41 trillion per year. A significant portion of these defects are regressions — things that worked and no longer do.

Regression testing is not a luxury. It's a fundamental quality assurance practice. And yet, many teams still treat it as an optional chore.

The three major types of regression testing

When we talk about "regression testing," we're actually referring to three distinct families. Each targets a different aspect of your application, and ignoring any of them is like only locking one out of three doors.

Functional regression testing

This is the most well-known. It verifies that existing features continue to produce the expected results after a change. Does your signup form still accept valid email formats? Does your cart correctly calculate the total with tax? Does your API return the right HTTP codes?

Functional testing answers the question: "Does it still work?"

It's the historical pillar of QA. Frameworks like Selenium, Playwright, or Cypress allow you to automate these checks. Most mature teams have at least a functional test suite. Good.

But "it works" doesn't mean "it looks right."

Performance regression testing

This one verifies that response times, memory consumption, and load capacity haven't degraded. You added a feature? Great. But if your page now takes 8 seconds to load instead of 2, you just lost 53% of your mobile visitors (source: Google, Web Performance Report 2023).

Tools like Lighthouse, k6, or JMeter let you integrate these checks into your pipeline. Yet few teams actually automate performance regression testing. Most settle for one-off benchmarks.

Visual regression testing

And here's the neglected child. The unloved one. The one that almost nobody automates, even though it's the most directly perceivable by your users.

Visual regression testing verifies that the appearance of your interface hasn't changed unexpectedly. A button going from blue to transparent. A title overflowing its container. A font reverting to the generic default. Spacing that disappears.

Your functional tests will say: "The button exists, it's clickable, it triggers the right action." All green. But if that button has become invisible because it's the same color as the background, your user will never find it.

This is the massive blind spot of modern QA. And that's exactly why tools like Delta-QA exist: to bridge the gap between "it works" and "it looks right."

When to run your regression tests

The short answer: with every change. The realistic answer: it depends on your strategy.

On every commit (CI/CD)

The ideal. Every push triggers an automated test suite. If something breaks, the developer knows immediately, before the code even reaches the main branch. This is the "shift left" model — detect problems as early as possible in the development cycle.

Before every release

The bare minimum. You accumulate changes during a sprint, and before shipping, you run the full suite. It's less reactive, but it's better than nothing. The risk: when a test fails, you have to search through all the sprint's changes to find which one caused the regression.

After a dependency update

Often forgotten, always critical. You update React, Angular, a CSS library, or a plugin? Run your regression tests. Third-party dependencies are a major source of silent regressions, especially visual ones. A version change in your CSS framework can shift margins, alter fonts, or break entire layouts.

After a production hotfix

You just fixed a bug in a rush. The temptation is to ship the fix as fast as possible. That's understandable. But a hasty hotfix without regression testing is the best way to turn one problem into two.

How to effectively automate your regression tests

Automation isn't a choice, it's a necessity. As your application grows, manual testing becomes physically impossible. Nobody is going to manually click through 500 user journeys on every deployment — and if someone tries, they'll miss things. The human eye tires. Automation never does.

The pyramid strategy

The classic test pyramid (Mike Cohn, 2009) recommends a broad base of unit tests, a middle layer of integration tests, and a narrow top of end-to-end tests.

For regression, this pyramid remains relevant, but it's missing a floor: visual testing. It should sit alongside E2E tests — same scope (full pages, real user journeys), but a completely different verification angle.

Imagine your test pyramid without visual verification. It's like a security system that detects intrusions but not fires. You cover one risk, not the other.

Choosing the right tools

For functional regression, there's no shortage of options: Playwright, Cypress, Selenium, TestCafe. Choose the one that matches your stack and skills.

For performance regression, Lighthouse CI, k6, and Artillery are solid choices.

For visual regression, the landscape is more fragmented. You can choose between solutions integrated into test frameworks (like Playwright's toHaveScreenshot()), specialized SaaS platforms (Percy, Applitools), or no-code tools that allow the entire team to contribute — not just developers.

And here's where honesty is needed: if only your developers can create and maintain your visual regression tests, you'll never have enough. Developers already have too much on their plate. Visual QA must be accessible to those who know the expected interface best: QA engineers, designers, product owners.

Pitfalls to avoid

The "test everything" trap. You don't need to test every pixel of every page. Focus on critical journeys: the homepage, the conversion funnel, the main dashboard, the most visited pages.

The false positives trap. This is the bane of visual testing. Dynamic content (dates, ads, avatars) changes between two captures and triggers a false alert. Good tools handle this with exclusion zones or smart comparison algorithms. Bad tools drown you in alerts until you ignore them — which is the same as not testing at all.

The "we'll do it later" trap. The longer you wait to automate, the more painful it gets. Start small: 10 tests on your critical pages. Then expand gradually.

Visual regression testing: why it's the most impactful

Let's take a step back. What does your user see when they land on your site? They don't see your API. They don't see your unit tests. They don't see your CI/CD pipeline.

They see the interface. The colors, the fonts, the spacing, the buttons, the images. It's their first impression. And according to a Stanford Persuasive Technology Lab study, 75% of users judge a company's credibility based on its website design.

A functional bug — the user forgives it: "it happens." A visual bug — they judge it: "that's unprofessional."

And yet, in most teams, visual verification is still done manually, by a QA who opens the site and "checks if everything looks fine." That's like asking someone to proofread an 800-page novel for typos with the naked eye — we all know how that ends.

Automating visual regression testing is no longer optional in 2026. It's what separates teams that ship with confidence from those that cross their fingers.

Regression testing in an agile team

In an agile context with short sprints and frequent deployments, regression testing becomes even more critical.

Each sprint adds features. Each feature is a potential regression risk. And since sprints are short (2 weeks on average), there's no time to test everything manually.

The solution: an automated regression suite that runs continuously. Functional tests in the CI pipeline. Performance tests in nightly builds. And visual tests — ideally accessible to the entire team, not just developers.

That's precisely the value of no-code approaches to visual testing: letting QA engineers, POs, and designers create and validate visual regression tests without depending on the dev team. Team autonomy is strengthened, and test coverage improves too.

FAQ

What's the difference between a regression test and a functional test?

A functional test verifies that a feature works correctly. A regression test verifies that this same feature continues to work after a code change. In practice, a functional test becomes a regression test as soon as you re-run it after a change.

How often should you run regression tests?

Ideally on every commit via your CI/CD pipeline. At minimum, before every release and after every dependency update. The more often you test, the faster you identify the change responsible for a regression.

Can you do regression testing without coding?

For functional regression, you generally need to code or use record-and-playback tools. For visual regression, no-code solutions exist — like Delta-QA — that allow any team member to create visual tests without writing a single line of code.

What are the best tools for automating regression tests in 2026?

It depends on the type of regression. For functional: Playwright, Cypress, Selenium. For performance: Lighthouse CI, k6. For visual: Delta-QA (no-code), Percy (SaaS), Applitools (enterprise), or Playwright's native toHaveScreenshot() function if you're a developer.

How do you handle false positives in visual regression testing?

False positives are the main barrier to visual testing adoption. The solutions: use exclusion zones for dynamic content, choose an appropriate comparison algorithm (perceptual rather than pixel-by-pixel), and prefer tools that analyze CSS structure rather than raw pixels — which eliminates false alerts from rendering differences.

Does visual regression testing replace functional tests?

Absolutely not. The two are complementary. Functional testing verifies that behavior is correct. Visual testing verifies that appearance is correct. You need both. A button can work perfectly while being invisible on screen — the functional test passes green, but the user can't click it.

Conclusion

Regression testing is not a glamorous topic. Nobody starts a startup to do regression testing. But it's the safety net without which everything else falls apart.

If you take away just one thing from this guide: don't neglect visual regression. It's the least automated type of testing, the most underestimated, and yet the most directly visible to your users. A site that "works" but "looks broken" is a site that loses customers.

Delta-QA was designed precisely to fill this gap: a no-code visual regression testing tool, free in its desktop version, that keeps your data local and detects visual anomalies that your functional tests can't see.

We build Delta-QA, a visual regression testing tool. Always open to feedback from the community!

Cypress Visual Testing: The Complete Guide to Adding Visual Testing to Cypress

Delta-QA — Wed, 29 Apr 2026 08:00:10 +0000

Cypress Visual Testing: The Complete Guide to Adding Visual Testing

Visual testing is an automated verification method that compares screenshots of a web interface against reference images to detect any visual regression — a misaligned button, a changed font, an element overlapping another.

Cypress is a fantastic tool. We love it for its speed, its intuitive API, its massive community. But let's be upfront: Cypress does not do visual testing natively. Unlike Playwright which includes toHaveScreenshot() out of the box, Cypress forces you to tinker with third-party plugins to get any kind of screenshot comparison.

And that's a more serious problem than it appears.

This guide reviews the existing approaches to adding visual testing to Cypress, their real limitations, and why a radically different approach deserves your attention.

Why Cypress Has No Built-in Visual Testing

This is the question nobody asks loudly enough. Playwright did it. Why not Cypress?

The official answer is diplomatic: Cypress focuses on functional testing. The honest answer is more nuanced. Visual testing is a complex problem — baseline management, tolerance for rendering differences, anti-aliasing, animations — and Cypress chose to let its plugin ecosystem handle it.

The result? Fragmentation. Each plugin does things its own way, with its own conventions, its own bugs, and its own risk of abandonment. You're not choosing one officially supported solution. You're betting on an open source project maintained by a handful of contributors — or on a paid cloud service.

For teams that have built their entire test suite on Cypress, it's a real dilemma. Migrating to Playwright just for visual testing isn't realistic. Adding a fragile plugin isn't either. Let's see what's available.

Approach 1: cypress-image-snapshot

The most popular plugin in the ecosystem. It relies on jest-image-snapshot (itself based on pixelmatch) to compare screenshots pixel by pixel.

How It Works

Installation requires a few tweaks to Cypress configuration — nothing insurmountable, but enough files to touch that mistakes can easily slip in. If you want the exact commands, ask your favorite AI assistant to generate the config — it loves that kind of thing, and it'll keep it busy between haikus about machine learning.

Once in place, the concept is simple: you add a custom command to your tests that captures the screen and compares it to a reference image stored in your repo. The first run creates the baseline. Subsequent runs detect differences.

The Limitations Nobody Tells You About

The maintenance problem. This plugin has gone through extended periods of inactivity. When you're reading this, check the date of the last commit on GitHub. If it's more than six months old, ask yourself some hard questions.

False positives. Pixel-by-pixel comparison is brutal. A slightly different font rendering between your machine and CI? False positive. Anti-aliasing that varies by GPU? False positive. You spend more time calibrating tolerance thresholds than writing tests.

No review interface. When a test fails, you get a diff image in a folder. No dashboard, no approval workflow. You open the image in your file explorer and squint to find the difference. It's artisanal at best.

Baseline management in Git. Hundreds of PNG images in your repo. Merge conflicts on binary files are a nightmare. Git history bloats. Some teams end up using Git LFS, adding yet another layer of complexity.

Approach 2: Percy (BrowserStack)

Percy is a cloud visual testing service that integrates with Cypress via an SDK. The approach is fundamentally different: instead of comparing locally, Percy sends the DOM and assets to its servers, renders the page in real browsers, and compares the results in a web dashboard.

How It Works

You install the Percy SDK for Cypress, add a call in your tests to capture a snapshot, and Percy handles the rest in the cloud. The review workflow happens in Percy's web interface: you see the differences, you approve or reject.

For the exact configuration, your desktop AI can spit out the snippet in three seconds — it's its moment to shine, let it rather than copy-pasting from docs that'll be outdated in six months.

The Limitations

Cost. Percy is a paid service. A free plan exists but it's limited in monthly snapshots. For a team that tests seriously, costs add up fast. We won't detail pricing here — it changes regularly — but expect a significant budget line item.

Cloud dependency. Your snapshots are rendered on Percy's servers. If the service goes down, your tests fail. If BrowserStack (which acquired Percy) decides to change pricing or terms, you have no leverage.

CI latency. Sending the DOM to an external service, waiting for rendering, retrieving the result — it adds time to your pipeline. Not dramatic for ten tests, but for five hundred, you'll feel it.

Vendor lock-in. Once all your baselines are in Percy, migrating elsewhere means recreating everything from scratch. It's the classic proprietary cloud service trap.

Approach 3: Happo

Happo is a lesser-known alternative to Percy, with a similar positioning: a cloud service that captures and compares screenshots of your components.

The Cypress integration exists but it's less mature than Percy's. The product is solid, the team is serious, but the user base is smaller. Less community documentation, fewer Stack Overflow answers, fewer experience reports.

The same cost and cloud dependency issues apply.

Approach 4: Applitools Eyes

Applitools takes the concept further with its AI-based comparison technology (their "Visual AI"). Instead of pixel-by-pixel comparison, the algorithm tries to detect "visually significant" differences while ignoring minor rendering variations.

It's appealing on paper. In practice, the product is powerful but complex. Configuration isn't trivial, pricing is opaque, and dependence on a proprietary service is total. For a detailed analysis, check our Applitools review.

The Root Problem: Visual Testing as an Add-on

All these approaches share a structural flaw: they treat visual testing as an add-on to functional testing.

You have your Cypress suite. You graft on a plugin or SDK. You add calls to your existing tests. Visual testing becomes a parasite on functional testing — dependent on the same infrastructure, the same selectors, the same code.

When Cypress ships a major version update, your visual testing plugin breaks. When your functional test changes its path, your visual baseline becomes obsolete. When a developer modifies a selector, both the functional test AND the visual test fail.

It's a fragile model by design.

Visual testing deserves to be a first-class citizen, not a stowaway in your functional suite. It answers a different question ("does it look right?" vs "does it work?") and should have its own tools, its own workflows, its own baselines.

What Your Cypress Tests Don't See

A Cypress test verifies that the button exists and triggers the right action. It doesn't verify that the button is visible, properly aligned, the right color, with the right padding, across all breakpoints.

Visual bugs are sneaky because they pass all functional tests. The form works perfectly — but the label overlaps the input on mobile. The dropdown menu opens correctly — but it appears behind another element. The displayed price is correct — but the currency shows white on white background.

These bugs reach production because nobody looks for them systematically. And they're expensive: in credibility, in conversions, in support tickets. To understand what visual testing actually detects, concrete examples often speak louder than theory.

The Alternative: Separating Visual Testing from Code

What if visual testing didn't need Cypress at all?

That's the position we defend at Delta-QA, and we fully own it. Visual testing doesn't need code. It doesn't need plugins. It doesn't need CSS selectors or webpack configuration.

Delta-QA works differently. You browse your site, record a journey with point-and-click, and the tool captures reference screenshots. On each subsequent run, it compares and shows you the differences in a dedicated interface. No code. No plugin. No dependency on Cypress, Playwright, or anything else.

This isn't a compromise. It's a different philosophy. Functional testing and visual testing are two distinct disciplines that each deserve their own tools. Your Cypress suite continues verifying that everything works. Delta-QA verifies that everything looks right. They complement each other without stepping on each other's toes.

For QA teams that don't code, it's liberating. For developers, it's time saved. For everyone, it's fewer false positives and a review workflow that makes sense. Discover why no-code visual testing is changing the game.

FAQ

Can Cypress do visual testing without a plugin?

No. Cypress can take screenshots with cy.screenshot(), but it offers no native comparison mechanism. You get images, but comparing them against baselines, managing tolerance thresholds, and the approval workflow must be added via a plugin or external service.

What's the best Cypress plugin for visual testing?

There's no universal answer. cypress-image-snapshot is the most popular open source option but suffers from maintenance issues and false positives. Percy offers the best user experience but it's a paid service. The "best" depends on your budget, your tolerance for false positives, and your willingness to maintain extra code.

Is Percy free with Cypress?

Percy offers a free plan with a limited number of monthly snapshots. For serious professional use, you'll need a paid plan. Pricing changes regularly — check their site for current terms.

Can you do Cypress visual testing in CI/CD?

Yes, all described approaches work in CI/CD. But that's where problems multiply: rendering differences between environments, baseline management, execution time. CI amplifies every fragility in your visual testing setup.

Why not just use Playwright for visual testing?

If you're starting a new project, Playwright with its native toHaveScreenshot() is indeed a better choice for code-based visual testing. But if you already have a substantial Cypress suite, migrating isn't realistic. And even with Playwright, you remain in the code-based visual testing paradigm, with its maintenance and accessibility limitations.

Can Delta-QA replace Cypress tests?

No, and that's not the goal. Cypress excels at functional testing: verifying that interactions work, that APIs respond correctly, that business logic is respected. Delta-QA focuses on visual testing: verifying that the interface looks right. The two tools are complementary, not competitors.

How long does it take to set up visual testing in Cypress?

With cypress-image-snapshot, expect one to two hours for basic installation and configuration, then several days to calibrate tolerance thresholds and stabilize tests against false positives. With Percy, technical setup is faster but organizational setup (snapshot management, review workflow, CI integration) takes time. With Delta-QA, the first visual test is up and running in minutes.

Conclusion

Cypress is an excellent functional testing tool. We use it, we recommend it for what it does well. But pretending it handles visual testing satisfactorily is self-deception.

Plugins exist. They work, more or less. But they're fragile, poorly maintained for some, expensive for others, and they all add complexity where none is needed.

Visual testing deserves better than a plugin. It deserves a dedicated tool, built for this specific problem, accessible to the entire team — developers and non-technical QA alike.

We build Delta-QA, a visual regression testing tool. Always open to feedback from the community!

Delta-QA vs BackstopJS: No-Code Visual Testing vs Manual Configuration

Delta-QA — Tue, 28 Apr 2026 08:08:59 +0000

Comparison: Delta-QA or BackstopJS, Which Free Tool for Your Visual Tests?

BackstopJS and Delta-QA share a rare trait on the market: they're both free, unlimited, and run locally. No cloud, no subscription, no snapshot counter. But that's about their only commonality.

BackstopJS is an open source tool for developers. Delta-QA is a desktop application for the whole team. The difference boils down to one question: who will create and maintain the tests?

The BackstopJS Approach

BackstopJS works with a JSON configuration file where you declare pages to test, viewports, and optional areas to mask. Then Puppeteer (Chrome) captures the pages and compares screenshots to locally stored baselines.

You'd normally expect us to show you the JSON file here. But let's face it, in 2026 you ask "generate a backstop.json for my site" to your AI and it's done in 5 seconds. What doesn't change is that you need to understand the structure, maintain it when pages change, and debug when tests fail.

The tool generates a visual HTML report with side-by-side comparisons — clear and readable. But the entire workflow goes through the terminal: backstop test, backstop approve, backstop reference.

The Delta-QA Approach

Delta-QA requires no configuration. No JSON, no terminal, no CLI. You open the application, enter the URL, browse the site. The tool records actions and captures pages. To compare, you replay the scenario.

The report is just as visual as BackstopJS — side-by-side comparison, highlighted differences. But creating the test takes 2 minutes instead of 20.

Chrome Only vs Multi-Browser

BackstopJS works exclusively with Puppeteer, meaning Chrome (Chromium). If you want to test Firefox or Safari, you need another tool.

Delta-QA supports Chrome, Firefox, and WebKit (Safari). Your site displays differently across browsers — that's a fact cross-browser testing addresses. With BackstopJS, you won't know about it.

Maintenance

With BackstopJS, every URL change, page identifier change, viewport or mask zone modification requires editing the configuration file. On a 50-page site, the JSON file becomes long and fragile.

With Delta-QA, modifying a scenario means re-recording it. A few clicks, no file editing.

The Real Cost of "Free"

Both tools are free. But the cost isn't the license — it's time.

BackstopJS is free in license but costs developer time: initial setup, config writing, JSON file maintenance, false positive debugging, baseline management. That's dev time not producing features.

Delta-QA is free in license and time. QA creates tests in minutes without involving a developer.

False Positives

BackstopJS does raw pixel diff. Anti-aliasing variations, font rendering differences between runs, sub-pixel micro-shifts — all generate false positives that need manual sorting.

Delta-QA uses structural CSS comparison that doesn't depend on graphical rendering. Zero false positives across 429 validated cases.

Who Is It For?

BackstopJS is the right choice if you're a developer, if you like the command line, if Chrome alone suffices, and if you have time to maintain the configuration.

Delta-QA is the right choice if your QA team wants autonomy, if you need multi-browser, if you want results without going through the terminal, or if you're looking for the simplest visual testing to set up.

FAQ

Is BackstopJS still maintained?

BackstopJS is a community open source project. It's less actively maintained than commercial solutions. Issues and PRs can remain open for a long time.

Which is faster to install?

Delta-QA: download and open (30 seconds). BackstopJS: npm install backstopjs, create config file, generate baselines (15-30 minutes minimum).

Can you migrate from BackstopJS to Delta-QA?

Yes. No data to migrate — baselines are recreated by recording scenarios in Delta-QA. Migration takes a few hours to recreate the main tests.

Does BackstopJS support user journeys?

Partially. BackstopJS can run Puppeteer scripts before capture (click, fill forms), but you need to write them in JavaScript. Delta-QA records journeys by browsing — no code.

BackstopJS and Delta-QA are both free and local. The difference fits in one sentence: BackstopJS requires a developer to configure and maintain tests. Delta-QA lets anyone on the team create them in a few clicks.

Previous article: Delta-QA vs Chromatic

We build Delta-QA, a visual regression testing tool. Always open to feedback from the community!

Delta-QA vs Chromatic: Testing Full Pages vs Testing Components

Delta-QA — Mon, 27 Apr 2026 08:00:52 +0000

Comparison: Delta-QA or Chromatic, Testing Full Pages or Components?

Chromatic is the reference tool for visual testing of UI components via Storybook. Delta-QA tests complete web pages with real user journeys. These aren't direct competitors — they're two different levels of testing. And understanding the difference prevents thinking you're protected when you're only half-covered.

What Chromatic Tests

Chromatic captures each Storybook story and compares it to its previous version. A button in its 5 states. A card with short and long titles. An empty and pre-filled form.

It's powerful for protecting a component library. Any modification to a shared component is immediately detected. The review interface is excellent for designer-developer collaboration.

The problem is that Chromatic tests components in isolation. A component alone, in a neutral container, without page context. And that's where bugs hide.

What Delta-QA Tests

Delta-QA tests complete pages. Not isolated components — real pages with real layouts, real content, real components interacting with each other.

A perfect Card component in Storybook can break when placed in a 3-column grid with a sidebar. A button validated in isolation can disappear behind a footer in real context. A flawless form in a story can overflow its container when integrated into a modal.

These bugs? Chromatic doesn't see them. Delta-QA does because it tests what users actually see — the complete page, in a real browser, with real content.

The Storybook Prerequisite

Chromatic requires Storybook. If your project doesn't use Storybook, Chromatic makes no sense. And setting up Storybook solely for visual testing is a considerable investment: writing stories for each component, keeping them up to date, managing demo data.

Delta-QA requires nothing. No Storybook, no specific framework, no code. You have a website? You can test it.

Cloud vs Local

Chromatic is exclusively cloud. Your screenshots are sent and stored on Chromatic's infrastructure. No self-hosted option.

Delta-QA is local by default. Everything stays on your machine. No data leaves.

Pricing

Chromatic offers 5,000 free snapshots per month, but only on Chrome. Multi-browser starts at $179/month. And snapshots add up fast: 180 stories × 3 viewports = 540 snapshots per build, roughly 9 builds before hitting the free limit.

Delta-QA Desktop is free with no limits. Multi-browser included.

The Real Question

The question isn't "Chromatic or Delta-QA?" It's "are you testing your components, your pages, or both?"

If you have Storybook and a design system, Chromatic protects your component library. That's a first safety net.

But you also need a second net for complete pages. That's where Delta-QA comes in. The two tools complement each other — neither replaces the other.

And if you don't use Storybook, Delta-QA is the only option you need.

FAQ

Does Chromatic work without Storybook?

Chromatic has been opening up to Playwright and Cypress since 2025, but these integrations are still young. In practice, Storybook remains the main prerequisite.

Can a perfect Storybook component break on a page?

Yes. Storybook isolation masks interactions with the parent layout, neighboring components, real content, and screen constraints. That's the main trap of isolated component testing.

Can you use Chromatic and Delta-QA together?

Yes, and it's the recommended approach. Chromatic for components, Delta-QA for pages. Each tool covers a different level.

Which is faster to set up?

Delta-QA: a few minutes. Chromatic: several hours to a few days (Storybook setup + writing stories + CI configuration).

Chromatic tests isolated UI components via Storybook. Delta-QA tests complete web pages and real user journeys — without Storybook, without code, without technical skills.

Previous article: Delta-QA vs Percy

We build Delta-QA, a visual regression testing tool. Always open to feedback from the community!

Delta-QA vs Percy: Which Visual Testing Solution Should You Choose?

Delta-QA — Sun, 26 Apr 2026 08:00:22 +0000

Comparison: Delta-QA or Percy, Which Solution for Your Visual Tests?

Percy is one of the most popular visual testing tools on the market. Acquired by BrowserStack in 2020, it benefits from a solid ecosystem and mature CI/CD integration. Delta-QA approaches the problem from a completely different angle.

Both tools detect visual regressions. But they don't target the same people, don't work the same way, and don't handle your data the same way. This comparison lays out the differences plainly.

Two Opposing Philosophies

Percy is a developer tool. It works through an SDK integrated into existing test code (Cypress, Playwright, Selenium). You add a percySnapshot() call in your script, run CI, Percy captures the DOM, sends it to its cloud, renders it in real browsers, and compares the result.

Delta-QA is a tool for the whole team. You install the application, open the site, browse normally. The tool records actions and compares screenshots. No code, no SDK, no pipeline to configure.

That's the fundamental difference. With Percy, the developer decides what to test and maintains the tests. With Delta-QA, the QA engineer, product manager, or designer can create and manage their own tests — using their product knowledge, not coding skills.

Installation

To use Percy, you need to install the SDK in an existing project, configure an API token in your CI environment variables, modify test scripts to add capture points, and run everything through the Percy CLI. A developer comfortable with CI/CD tooling can do this in a few hours.

At this point, you'd normally expect us to show you the npm commands and config lines. But let's be realistic: in 2026, you'll copy that from the Percy docs in 30 seconds, or ask your favorite AI.

To use Delta-QA, you download the app and open it. That's it. The first test is possible in under 5 minutes.

Where Do Your Screenshots Go?

With Percy, your screenshots go to the BrowserStack cloud. The DOM is sent to their servers, rendered in their browsers, and baselines are stored in their infrastructure. There is no on-premise option.

With Delta-QA, everything stays on your machine. No data leaves. For companies with GDPR constraints or interfaces containing sensitive data, this is a decisive criterion.

The False Positive Question

Percy uses pixel comparison after rendering in real browsers. Since late 2025, a "Visual Review Agent" powered by AI filters roughly 40% of false positives related to anti-aliasing and font rendering variations. That's progress, but it means 60% of the noise still needs manual sorting.

Delta-QA uses a 5-pass structural algorithm that analyzes actual CSS rather than comparing pixels. Result: zero false positives across 429 validated test cases. The tool doesn't filter noise — it doesn't generate it.

Pricing

Percy offers a generous free tier: 5,000 snapshots per month, unlimited users. But beware the trap: each viewport counts as a snapshot. If you test 10 pages across 3 resolutions, that's 30 snapshots per run. At 2 runs per day, you hit the limit in 2-3 weeks.

Beyond that, paid plans start around $99/month and scale quickly with volume.

Delta-QA Desktop is free with no limits whatsoever. No snapshot counter, no time limit, no signup. Team and Business versions for teams are fixed-price, no surprises.

Who Is It For?

Percy is the right choice if your team is made up of developers, if you have a well-established CI/CD pipeline, if you already use BrowserStack, and if data location isn't a constraint.

Delta-QA is the right choice if your QA team isn't made up of developers, if you want to test without depending on CI, if screenshot privacy matters, or if you're looking for a free solution without limits.

FAQ

Is Percy free?

The free tier offers 5,000 snapshots/month. That's enough to evaluate the tool, but the limit is quickly reached with daily use across multiple viewports. Delta-QA Desktop is free with no limits.

Can you use Percy without CI/CD?

Technically yes, but Percy is designed to work in a pipeline. Using it outside CI is possible but impractical. Delta-QA works standalone, no CI needed.

Which has fewer false positives?

Delta-QA, thanks to structural CSS analysis rather than pixel comparison. Percy has reduced its false positives with AI since late 2025, but hasn't reached zero.

Can Percy run on-premise?

No. Percy is exclusively cloud (BrowserStack). Delta-QA offers a local Desktop version and an On-Premise version for enterprise servers.

Percy is an excellent visual testing tool for development teams with a mature CI/CD pipeline. Delta-QA is for everyone else: QA engineers, designers, product managers — anyone who needs to visually verify a web page without writing code.

Previous article: Screenshot Comparison: pHas/h and SSIM

We build Delta-QA, a visual regression testing tool. Always open to feedback from the community!

Visual Testing for E-commerce: Protect Your Revenue

Delta-QA — Sat, 25 Apr 2026 08:01:33 +0000

Visual Testing for E-commerce: Protect Your Revenue

On an e-commerce site, every pixel matters. An "Add to Cart" button that disappears on mobile, a checkout form that overflows its container, a price that displays incorrectly — these aren't cosmetic details. They're lost sales.

The problem is these bugs are silent. Your server monitoring says everything's fine. Your functional tests pass green. But your customers see a broken interface and leave for the competition without saying a word.

What does an e-commerce visual bug cost?

A concrete example: a site with 10,000 daily visitors, 2% conversion rate, and $80 average cart. That's 200 orders per day, $16,000 in daily revenue.

Now imagine a CSS update makes the checkout button invisible on Safari mobile (roughly 25% of traffic). Over a weekend (3 days): 3 × 50 lost orders × $80 = $12,000 gone. For a CSS change nobody saw coming.

Visual bugs are expensive, and e-commerce is the sector where the impact is most immediate and measurable.

Critical pages to monitor

Homepage — your storefront. First impression. A broken carousel or missing product image and visitors bounce.

Product pages — your sales arguments. Price must be visible and correctly formatted. The "Add to Cart" button must be accessible on all screens.

Cart — the customer already decided to buy. Any visual friction here causes abandonment.

Checkout — the most critical page. If the payment form displays poorly, customers don't pay. Worse, a visually broken payment form signals an insecure site.

Confirmation — reassures the customer their order went through. If it renders incorrectly, they call support.

Why standard tests aren't enough

Functional tests check that the "Buy" button exists in the DOM and triggers the right action. They don't check if it's visible on screen. They don't check if the price displays correctly in all currencies. They don't check if the layout holds on a 375px screen.

Visual testing fills this blind spot.

Most common causes of e-commerce visual bugs

Dependency updates, cross-browser changes, marketing content modifications (title too long pushing the button off-screen), and responsive issues (perfect on desktop, broken on mobile — where 60% of e-commerce traffic comes from).

How to protect your site

Level 1 — Visual test on your 10 most critical pages before each deployment.
Level 2 — Regular monitoring of production pages.
Level 3 — Full catalog coverage, all product variations, all checkout states.

With a no-code tool like Delta-QA, the QA team can set up levels 1 and 2 in hours, without depending on the dev team.

FAQ

What's the average cost of a visual bug on an e-commerce site?

Depends on traffic and average cart, but a checkout bug can cost $5,000-$50,000 per day on a medium site.

Which e-commerce pages to test first?

Checkout tunnel first (cart, payment, confirmation). Then homepage and product pages.

How to test responsive without spending hours?

An automated visual testing tool tests multiple resolutions in parallel. Seconds instead of hours.

Previous article: Visual Testing with Playwright: The Complete Tutorial

We build Delta-QA, a visual regression testing tool. Always open to feedback from the community!

GDPR and Visual Testing: Why Your Screenshots Shouldn't Leave Europe

Delta-QA — Fri, 24 Apr 2026 08:01:37 +0000

GDPR and Visual Testing: Why Your Screenshots Shouldn't Leave Europe

Every time you run a visual test with a cloud tool, your screenshots go to remote servers. These screenshots often contain much more than a simple web page: internal dashboards with client data, admin interfaces, unreleased product mockups, pre-filled forms with real data.

The question isn't technical. It's legal and strategic: where does your test data go, and who has access?

What your screenshots really contain

When you think "test screenshot," you imagine a public homepage. In reality, QA teams mostly test internal interfaces and authenticated journeys:

Management dashboards with real revenue figures. Back-offices with client names, addresses, order numbers. Payment interfaces with partially visible bank details. Feature mockups not yet publicly announced. Staging environments that replicate production data.

Each of these screenshots is potentially sensitive data. And with most visual testing tools on the market, all these screenshots are automatically sent to the cloud — often to the United States.

The problem with American cloud tools

The majority of popular visual testing tools — Applitools, Percy (BrowserStack), Chromatic — are American companies whose servers are hosted in the US or operated by companies subject to American law.

The GDPR (General Data Protection Regulation) imposes strict constraints on transferring personal data outside the European Union. Since the Court of Justice of the EU invalidated the Privacy Shield in 2020 (Schrems II ruling), data transfer to the United States is legally complex.

Concretely, if your screenshots contain personal data (a name, address, or client number visible on screen), sending them to an American server without appropriate guarantees may constitute a GDPR violation.

And beyond strict GDPR compliance, there's the question of intellectual property. Your interfaces, mockups, and visible business logic — all of that has value. Sending it to third-party servers is a risk many companies underestimate.

Industries where this is a real problem

Banking and finance: regulators impose strict requirements on data localization. A screenshot showing a client balance cannot transit through a foreign server without major precautions.

Healthcare: health data is among the most protected under GDPR. A hospital dashboard captured in a visual test is health data.

Defense and public sector: public tenders increasingly require sovereign solutions. No American cloud, period.

E-commerce: even a standard retail site captures names, addresses, and purchase histories in its back-offices.

B2B SaaS: your clients entrust you with their data. If your testing process exposes it to a third party, it's your contractual and legal responsibility.

The local approach: total control

The simplest solution is to never send screenshots outside your infrastructure.

That's exactly Delta-QA's approach. The Desktop version works entirely locally: screenshots are taken on your machine, compared on your machine, and stored on your machine. No data transits through an external server. No account to create, no API token, no cloud connection.

For teams needing to share results, the On-Premise version deploys on your own servers — in your datacenter, on your private cloud, or within your internal network. Data never leaves your perimeter.

This approach eliminates the GDPR question at its root: if data doesn't leave, there's no transfer to regulate.

Open source tools: a partial alternative

Open source tools like Playwright and BackstopJS also work locally by default. That's a real privacy advantage.

But they have a tradeoff: they require developer skills for installation, configuration, and maintenance. If your QA team doesn't have these skills, the tool won't be used by the right people.

Delta-QA combines both advantages: local by default (like open source) and no-code accessibility (unlike open source).

Beyond GDPR: sovereignty as a competitive advantage

The question goes beyond regulations. More and more European companies choose sovereign tools not by obligation, but by conviction.

Knowing exactly where your data is, who has access, and being able to prove it to your clients — that's a commercial advantage. In a tender, saying "our test data never leaves our infrastructure" can make the difference.

How to check where your data currently goes

If you already use a visual testing tool, ask these questions: Where are the servers hosting your screenshots? Under which jurisdiction does the company operate? Is data encrypted in transit and at rest? How long are screenshots retained? Can you request complete deletion? Is there an on-premise or European hosting option?

If your provider can't clearly answer these questions, it's a red flag.

FAQ

Does GDPR apply to test screenshots?

Yes, whenever a screenshot contains personal data — a name, email address, or client number, even partially visible. Test data has no special exemption under GDPR.

Is anonymizing test data enough?

Anonymization can reduce risk, but it's hard to guarantee on screenshots. A name visible in a corner, an address in a pre-filled form — one oversight is enough.

Does Delta-QA send data to the cloud?

No. The Desktop version works entirely locally. No screenshot, no data ever leaves your machine. The On-Premise version runs on your own servers.

Which visual testing tools are GDPR-compatible?

Tools that work locally (Delta-QA, Playwright, BackstopJS) are simplest to make compliant since there's no data transfer. Cloud tools (Applitools, Percy, Chromatic) require additional precautions.

Does "Made in France" guarantee GDPR compliance?

Not automatically, but a European publisher is directly subject to GDPR and doesn't face transatlantic transfer constraints. That's a structural advantage.

Test data privacy isn't a secondary concern. It's a legal, commercial, and strategic issue. Choosing a tool that keeps your data in-house isn't paranoia — it's good management.

Previous article: Visual Testing Tools Comparison 2026

We build Delta-QA, a visual regression testing tool. Always open to feedback from the community!

Visual Testing with Playwright: The Complete Tutorial

Delta-QA — Thu, 23 Apr 2026 08:05:29 +0000

Visual Testing with Playwright: The Complete Tutorial

Since version 1.22, Microsoft's Playwright includes a native visual testing feature: the toHaveScreenshot() method. It captures screenshots and automatically compares them to reference images, with no external plugin needed.

This is one of the strongest options for development teams wanting to add visual testing to their existing stack. This tutorial covers installation, configuration, best practices, and CI/CD integration.

Installation and first test

Setup is quick with an existing Node.js project:

npm install -D @playwright/test
npx playwright install

Create your first visual test in tests/visual.spec.ts:

import { test, expect } from '@playwright/test';

test('homepage visual test', async ({ page }) => {
  await page.goto('https://your-site.com');
  await expect(page).toHaveScreenshot('homepage.png');
});

First run generates the baseline. Subsequent runs compare against it. That simple to start — complexity comes with real-world cases.

Configuring tolerance

By default, Playwright flags any single-pixel difference. In practice, configure thresholds to avoid false positives:

// playwright.config.ts
expect: {
  toHaveScreenshot: {
    maxDiffPixelRatio: 0.01,
    animations: 'disabled',
    scale: 'device',
  },
}

Handling dynamic content

Three solutions: mask dynamic zones, replace content via page.evaluate(), or hide with injected CSS. Each has tradeoffs between reliability and maintenance.

Stabilizing tests

Wait for network idle, font loading, and critical element visibility before capturing. Disable animations globally in config.

Multi-resolution testing

Use Playwright projects to test Desktop (1920×1080), Tablet (768×1024), and Mobile (iPhone 13) with separate baselines per project.

CI/CD integration

GitHub Actions integration is straightforward. When tests fail, Playwright generates three images: baseline, actual screenshot, and a red-highlighted diff. The HTML report shows them side by side.

Limitations

TypeScript/JavaScript skills required. No built-in review dashboard. Pixel comparison remains basic — anti-aliasing and font rendering differences between browsers generate noise. Baseline management with 200+ tests across 3 browsers means 600+ files to maintain.

For teams wanting visual testing without these technical constraints, no-code solutions like Delta-QA offer an alternative: same result with zero code, zero manual baseline management, and zero false positives.

FAQ

Is Playwright free for visual testing?

Yes, entirely. toHaveScreenshot() is built into Playwright, which is open source.

Playwright or Cypress for visual testing?

Playwright has native visual testing; Cypress needs a plugin. Playwright supports three browser engines vs one for Cypress. For visual testing specifically, Playwright wins.

Can you use Playwright and Delta-QA together?

Yes. Playwright for complex dev tests, Delta-QA for routine visual checks by the QA team.

Previous article: From Manual to Automated Testing: A Guide for Non-Developer QAs

We build Delta-QA, a visual regression testing tool. Always open to feedback from the community!

No-Code Visual Testing: The Complete Guide for QA Teams

Delta-QA — Thu, 23 Apr 2026 08:02:01 +0000

No-Code Visual Testing: Automate Your Checks Without Writing Code

No-code visual testing is a method that automatically detects visual regressions on a website — a shifted button, a changed color, overflowing text — without writing a single line of code. You record a journey by browsing normally, then the tool replays it and compares screenshots pixel by pixel.

For 15 years, automating a test meant writing code. That's no longer the case. This guide is for QA professionals, product managers, and marketing teams — anyone who checks interfaces daily without being a developer.

The Problem: Automation Has Always Excluded Non-Developers

For a decade, the message has been the same in the software testing industry:

"QA engineers must learn to code to automate their tests."

The result has been a collective failure. Experienced QA teams, with 10 or 15 years in the field, are pushed toward tools like Selenium, Cypress, or Playwright that they don't master. Training is abandoned after a few weeks. Automated tests end up maintained solely by developers. And QA engineers feel sidelined.

An experienced QA excels at functional analysis, test case writing, and exploratory testing. These are skills that take years to build. But traditional automation requires mastering JavaScript, CSS selectors, and code debugging. These are two different jobs.

On one side, the QA knows the product better than anyone. They know which journeys to test, which scenarios are critical, where bugs hide. On the other side, traditional automation demands pure developer skills: writing code, maintaining scripts, managing dependencies. Asking a functional expert to become a developer is like asking an architect to lay the bricks themselves.

This gap is real. And bridging it takes months, even years. No-code testing eliminates this barrier entirely.

How No-Code Visual Testing Works

The concept is simple. The process follows four steps:

Open your website in the testing tool
Browse normally, like a real user (click buttons, fill forms, scroll pages)
The tool records every action automatically and takes a reference screenshot
Replay the scenario later: the tool compares new screenshots to references and highlights every difference

No JavaScript. No CSS selectors. No configuration files. No terminal.

The reference screenshot (called a "baseline") represents the validated state of your site. On each subsequent run, the tool overlays the current state against this reference and automatically detects what changed: a shifted pixel, a modified font, a missing element.

It's exactly what a human would do comparing two versions of a page side by side — except the robot never gets tired, never misses anything, and does it in seconds.

What Your Regular Tests Don't See

A standard functional test checks that elements are present. Is the "Buy" button there? Yes. Does the form work? Yes. Does the menu appear? Yes.

But what the test doesn't tell you is:

The "Buy" button has turned white on a white background — invisible to users
The form overflows its container on mobile
The menu covers the main content of the page

The site "works" technically, but it's visually unusable. This is exactly the blind spot that visual regression testing fills. It checks not whether elements exist, but whether they display correctly — the right color, the right size, in the right place.

From Installation to First Test: The Concrete Workflow

Here's how a no-code visual test works with a solution like Delta-QA:

Installation: Download the app, install it with a double-click. No npm, no terminal, no dependencies. 30 seconds is all it takes.

Recording: Create a new scenario, enter your site's URL. A browser opens. Browse normally on the pages you want to monitor. The tool records every action — every click, scroll, and input.

Execution: Click "Run." The tool replays your actions automatically and takes new screenshots.

Analysis: Differences are highlighted side by side. Green = identical. Red = difference detected. You instantly see what changed, without searching manually.

Time from installation to first test: a few minutes. Not days.

Approach	Setup	First 10 tests	Total
Playwright (code)	1-2 days	1 day	2-3 days
Percy (SaaS + code)	4-8 hours	4 hours	1-2 days
Delta-QA (no-code)	30 minutes	2-3 hours	3-4 hours

No-Code vs Code: An Honest Comparison

No-code is not a replacement for code. It's a complement. Here's an objective comparison.

Creating a product page test with code (Playwright, for example) means writing a script, configuring comparison options, and managing masks for dynamic content. Count 15 to 30 minutes if you're proficient.

With a no-code solution, you open the page, click "Capture," and stop recording. 2 minutes.

Maintenance is also simpler: when a selector breaks in code, you need to debug and fix the script. With no-code, you re-record the step in a few clicks.

But code retains real advantages for certain cases:

Conditional logic: if this promo is visible, test this path; otherwise, test the other
Dynamic data generation: create test users on the fly
Complex assertions: verify all prices in a list are greater than zero
Advanced API integration: validate server responses before testing the interface

These are cases where no-code reaches its limits. And that's normal: both approaches serve different needs.

Who Is No-Code Visual Testing For?

Experienced non-developer QA engineers

This is the primary audience. Professionals with 10+ years of functional experience, irreplaceable domain expertise, who want to automate without depending on the dev team. Their knowledge — what to test, when, and why — is infinitely more valuable than the ability to write a script. No-code finally lets them turn that expertise into automated tests.

Small teams and startups

No dedicated QA, no budget for complex test infrastructure, but a real need to verify the site doesn't break between deployments. The founder who deploys on Friday night and wants to sleep peacefully.

Non-technical teams

Marketing checking that the landing page hasn't shifted after a deployment. Support confirming a fix is in place. The product manager visually validating a feature before shipping.

The Business Impact: A Broken Interface Is Expensive

A visual error is never "just a cosmetic detail." Visual bugs have a real cost on your business:

Conversion drop: an invisible purchase button on mobile means a lost sale. Users don't search — they leave. A single second of display lag can drop your conversion rate by 7%.

Credibility loss: overflowing text, distorted images, misaligned forms — all signal amateurism. Trust built over months collapses in seconds.

High correction cost: detecting a visual bug in production costs 10 to 100 times more than catching it before deployment. Not to mention the reputation damage.

Automated visual testing turns a multi-hour manual check (often rushed due to fatigue) into a process that takes seconds and is 100% reliable.

The Privacy Question

Many visual testing tools require sending your screenshots to the cloud. Your internal dashboards, client data, in-development interfaces — everything goes to external servers, often located in the United States.

This is a real problem for companies subject to GDPR, for regulated industries (banking, healthcare, defense), or simply for teams that want to keep control over their data.

A local solution like Delta-QA keeps everything on your machine. No screenshot ever leaves your computer. It's the only approach that guarantees total sovereignty over your test data — a strong argument against US-based cloud solutions.

The Hybrid Strategy: Best of Both Worlds

The best approach for a complete team combines three testing layers:

Layer 1 — No-code tests (QA team): critical business pages, main user journeys, visual checks after every deployment. Maintained directly by the QA team.

Layer 2 — Coded tests (developers): complex tests with conditional logic, integration tests, dynamic data scenarios. Maintained by the dev team.

Layer 3 — Unit tests (developers): business logic, isolated components. The base of the testing pyramid.

This model lets each role contribute with their skills, without forcing anyone outside their expertise zone. QA does what they do best, devs too. Everyone is productive.

Best Practices for Getting Started

Start small: protect your 5 most critical pages first — homepage, cart, checkout, contact form, flagship product page. These are the pages where a visual bug has the most impact on your revenue.

Test all formats: a site that's perfect on desktop can be completely broken on mobile. Always check both. And if your users use Safari, test cross-browser too.

Build a routine: don't test once a month. Integrate visual testing into every deployment, even minor ones. A small CSS change can have unpredictable consequences.

Involve the whole team: no-code lets QA, designers, and product managers create and maintain tests. Use this to democratize visual quality across your organization.

FAQ

What is no-code visual testing?

It's a method to automatically detect visual changes on a website — shifted buttons, changed colors, missing elements — without writing code. You record a journey by browsing normally, then the tool replays it and compares screenshots pixel by pixel.

Do I need technical skills to use Delta-QA?

No. Delta-QA was designed for non-technical profiles. No code, no framework configuration. If you can browse a website, you can use Delta-QA.

What free tool can I use for visual regression testing?

Delta-QA offers a completely free Desktop version with no scenario or comparison limits. No signup, no credit card, no time limit.

Does no-code replace coded tests?

No. No-code complements coded tests. It's ideal for visual checks and critical journeys. Complex tests with conditional logic remain the domain of code. The best strategy is hybrid.

Where are my screenshots stored with Delta-QA?

Everything stays on your machine. No data is sent to an external cloud. This is essential for GDPR compliance and intellectual property protection.

What's the difference between a functional test and a visual test?

A functional test checks that elements exist and work (the button is clickable). A visual test checks that elements display correctly — the right color, the right size, in the right place. Learn more in our complete visual testing FAQ.

No-code visual testing isn't a passing trend. It's a necessary evolution that gives QA professionals the power to automate their checks without depending on the development team. Domain expertise — knowing what to test, when, and why — has always been more valuable than the ability to write a script. No-code finally lets that expertise translate into automated tests.

Previous article: Visual Testing FAQ: 20 Most Frequently Asked Questions

We build Delta-QA, a visual regression testing tool. Always open to feedback from the community!

AI vs Deterministic Algorithm: Which Detects Visual Regressions Better?

Delta-QA — Wed, 22 Apr 2026 11:45:07 +0000

AI vs Deterministic Algorithm: Which Detects Visual Regressions Better?

In visual testing, two philosophies compete. On one side, artificial intelligence that "learns" to recognize significant differences. On the other, deterministic algorithms that analyze actual CSS code to detect every change with certainty.

Both approaches have convinced supporters. But they don't serve the same need, and the choice between them has direct consequences on your test reliability.

The AI approach: how it works

The AI approach works through learning. The tool analyzes millions (even billions) of screenshots to train a model that "understands" what constitutes a significant visual difference for a human.

When you run a test, the AI compares the current screenshot to the baseline and automatically decides whether detected differences are "important" or "negligible." Slightly different anti-aliasing between browsers? Ignored. A button that changed color? Flagged.

The promise: reduce false positives — those alerts signaling differences nobody would notice with the naked eye.

The black box problem

The AI makes a decision, but doesn't explain its reasoning. When it decides a difference is "acceptable," you don't know why. When it lets through a change that turns out to be a real bug, you can't understand what happened.

This is the black box problem. And in QA, it's a real issue.

A QA engineer's role is to guarantee with certainty an application's correct behavior. A regression test must be reproducible and predictable. If the AI decides differently from one run to another, confidence in the result collapses.

The deterministic approach: certainty first

The deterministic approach makes the opposite choice. Rather than "guessing" whether a difference matters, it analyzes actual CSS code and computed properties of each element.

This is Delta-QA's approach. The algorithm works in 5 structural passes: it compares DOM structures, computed CSS properties, element dimensions and positions, colors and typography, and finally the pixel rendering. Each pass produces a deterministic result — the same code always produces the same result, every execution, without exception.

When a difference is detected, the tool says exactly what changed: "the font-size property of this element went from 16px to 14px," "the left margin of this container increased by 8px." No guessing, no interpretation — facts.

Result: zero false positives across 429 validated test cases.

False positives: the real hidden cost

Each false positive takes time to analyze and dismiss. After a few weeks, the team starts ignoring alerts — "it's another false positive." And the day a real bug slips among the alerts, nobody looks.

AI reduces false positives by ignoring certain differences. The deterministic approach eliminates them by being more precise in what it measures. The difference is fundamental: one masks the noise, the other removes it at the source.

When AI makes sense

AI has value when testing across many browser/resolution combinations and rendering variations generate unmanageable false positive volume. Or when your app contains heavy dynamic content.

When deterministic wins

The deterministic approach is preferable when result reliability matters more than triage comfort. When you need certainty in a deployment pipeline. When you want to understand what changed. When you work in a regulated sector where auditability is required. When your team is small and can't afford to sort false positives.

The real trend: AI upstream, not in the loop

The most interesting trend isn't using AI to execute tests. It's using it upstream to improve tool algorithms. AI can analyze millions of test cases to identify patterns causing false positives. But at execution time — when the test decides if your interface is correct — deterministic precision should have the final word.

FAQ

Is AI more accurate than a deterministic algorithm?

AI is better at filtering noise (anti-aliasing, cross-browser variations). Deterministic algorithms are more precise at detecting real CSS changes.

What is a false positive in visual testing?

When the tool flags a difference that isn't one for a human user. False positives waste time and erode test confidence.

Why doesn't Delta-QA use AI?

Delta-QA prioritizes predictability and explainability. AI is used upstream (research, algorithm improvement) but not in the test execution loop.

Can you combine both approaches?

Yes. Some teams use deterministic tools for critical tests and AI tools for broad monitoring.

Previous article: GDPR and Visual Testing

We build Delta-QA, a visual regression testing tool. Always open to feedback from the community!