Hello everyone! I’m Noam, an SDK developer on the Applitools JS-SDKs team. While my day-to-day focus is on core engineering, I work closely with our field teams and occasionally join technical deep-dive sessions with customers.

In these conversations, we frequently encounter questions about performance and the engineering philosophy behind our integration. Specifically, there is often curiosity about how to make visual testing feel more “Playwright-native” and natural to developers.

In this post, I’ll share the design logic behind these architectural choices so you can apply these patterns in your own CI pipelines in a way that fits your organization’s needs.

Adding unresolved to Playwright

Integrating visual regression testing into Playwright requires combining two different status models: Playwright’s binary Pass/Fail and the visual testing concept of unresolved.

In visual testing, instead of having two (passed and failed) states, there’s an additional third state: unresolved. This state indicates a difference was detected, but a human decision is required to determine if it is a bug or a valid change that should be approved as a new baseline.

​Playwright doesn’t support this third state out of the box. Visual test maintenance using Playwright’s native toHaveScreenshot API forces the developer into a cumbersome cycle requiring three separate test executions:

1. First, the developer needs to run to see the failure.
2. Then, they need to run with the --update-snapshots flag to create new baseline images.
3. Then, most developers would run again to validate that everything works with the updated baseline as expected—which isn’t always the case, because the Playwright native comparison method (pixelmatch) tends to be very flaky, unlike Visual AI.

​After this local cycle, the developer must commit the new baseline images to the repository—bloating the git history—and wait for a new CI execution to provide final feedback. For dev-centered organizations that focus on feedback loop velocity, this workflow is… suboptimal. Personally, I believe that’s one of the reasons visual testing isn’t as popular as it should be among Playwright users.

​When we engineered the Applitools fixture, one of our goals was to support this Unresolved state natively, without disrupting Playwright’s core lifecycle—specifically its Worker Processes and Retry mechanisms.

The solution rests on two key engineering decisions: moving rendering to the background (async architecture) and giving developers control over the exit signal and performance tradeoffs (failTestsOnDiff).

We don’t block test execution when Applitools is rendering

The core value of visual testing lies in AI-based comparison to eliminate false positives and multi-platform rendering.

Architecturally, these processes are cloud-native services.

• AI-as-a-Service: Just like massive LLMs or other generative models, the Visual AI engine runs on specialized cloud infrastructure optimized for heavy inference. It cannot simply be “installed” on a lightweight CI agent.
• Platform Constraints: Authentic cross-platform rendering (e.g., iOS Safari on a Linux CI agent) is physically impossible on a single local machine.

Since these operations inherently occur remotely, performing them synchronously would force the local test runner to idle while waiting for network round-trips and cloud processing.

To solve this, we designed the fixture around an asynchronous architecture:

• ​Instant Capture: When eyes.check() is called, we synchronously capture the DOM and CSS resources (instead of a rasterized image). This operation is extremely fast.
• ​Immediate Release: We purposefully use soft assertions by design. We release the Playwright test thread immediately so the functional logic can proceed to the next step or test case without blocking.
• ​Background Heavy Lifting: The heavy work—uploading assets, rendering across different browsers and operating systems, and performing the AI comparison in the Applitools cloud—starts immediately in the background, managed by the Worker process.

The “Draining Queue” Effect

​This architecture explains why the Playwright Worker sometimes remains active after the final test completes.

​The background tasks are limited only by your account’s concurrency settings, and the screenshot size. For example, when rendering a 10,000 px page on a small mobile device, the rendering infrastructure might need time for scrolling and stitching. If your functional tests execute faster than the background workers can process the queue (rendering & comparing), the Worker process stays alive at the end solely to “drain the queue” and ensure data integrity.

While it does ensure your test logic runs at maximum speed, offloading the processing cost to the background, this experience might cause friction and frustration as the developers see that workers are “hanging” after tests are completed. When facing such issues, our support team is here to advise and assist with various solutions—we can investigate execution logs and if needed even make custom suggestions to tailor Eyes-Playwright to your needs.

Solving the Matrix Problem

​Standard Playwright documentation recommends defining multiple projects in playwright.config.ts to cover different browsers (Chromium, Firefox, WebKit) and various viewport sizes.

​While this ensures coverage, it introduces a linear performance penalty (O(N)). To test three browsers across two viewports, your CI must execute the functional logic (clicks, waits, navigation) six times. It’s 6x more load on the CI machine and the testing environment.

​We recommend shifting this workload to the Ultrafast Grid (UFG).

​In this mode, you execute the Playwright test once, typically on Chromium. We upload the DOM state, and our cloud infrastructure renders that state across all configured browsers and viewports in parallel.

This transforms an O(N) execution problem into an O(1) execution problem, significantly shortening the feedback loop.

The Strategy: failTestsOnDiff

​Since the actual comparison happens asynchronously and potentially completes after the test logic finishes, we need a mechanism to map the visual result back to the Playwright status.

​This is controlled by the failTestsOnDiff flag. It’s not just a boolean; it’s a strategic choice for your CI pipeline.

​Strategy A—Recommended for CI: failTestsOnDiff: false

• ​The Logic: This is the configuration our own Front-End team uses. We believe that Visual Change ≠ Test Failure.
• ​Behavior: The Playwright test passes (Green). The unresolved status is reported externally via our SCM integration (GitHub/GitLab).
• ​Why: Retrying a visual test is computationally wasteful—the pixels won’t change on the second run. By keeping the test “Green,” we avoid triggering Playwright’s retry mechanism. The decision is moved to the Pull Request, where it belongs.

Read more about SCM integration or hop directly to our GitHub, Bitbucket, Gitlab or Azure Devops articles.

Strategy B—Recommended for Strict Pipelines: failTestsOnDiff: 'afterAll'

• ​The Logic: You need a “Red” pipeline to block deployment, but you want to avoid the noise of retries and gain a significant performance improvement.
• ​Behavior: Individual tests pass, but the Worker Process exits with a failure code if any diffs were found in the suite.
• ​Why: This provides a hard gatekeeper for the build status. It allows the Eyes rendering farms to continue processing visual test results in the background without blocking the execution thread, allowing the worker to move on to handle more tests efficiently.

​Strategy C—Recommended for Local Debugging: failTestsOnDiff: 'afterEach'

• ​The Logic: Immediate feedback loop.
• ​Behavior: Fails the test immediately in the afterEach hook.
• ​Why: Best for local development where you want to see the failure immediately in the console. It is also useful if you use the trace: retainOnFailure setting in Playwright, as it ensures traces are preserved for unresolved visual assertions. Not recommended for CI due to the retry loops described above.

TL;DR – When to use each setting

Closing the Visibility Gap: The Custom Reporter

​If you adopt Strategy A (false) or Strategy B (afterAll), you introduce a secondary challenge: Visibility.

Since Playwright technically marks these tests as Passed to avoid retries, the standard Playwright HTML Report will show them as “Green,” potentially masking unresolved visual differences that require attention.

​To bridge this gap without forcing developers to switch context, we developed a Custom Applitools Reporter.

​This reporter extends the standard Playwright HTML report. It injects the actual visual status (Passed, Failed, or unresolved) directly into the test results view.

• ​True Status: You see which tests have visual diffs, even if the Playwright exit code was successful.
• ​Direct Links: It provides a direct link from the test report to the specific batch results in the Applitools Dashboard.
• ​Context: It enriches the report with UFG render status and batch information.

​This ensures you get the best of both worlds: The optimization of a “Green” CI run (no retries), with the transparency of a report that highlights exactly where manual review is needed.

Summary

​The Applitools Playwright fixture is designed to be non-blocking and scalable. By leveraging asynchronous architecture and Applitools UltraFast Grid, we offload the heavy lifting from your CI. By correctly configuring failTestsOnDiff, you ensure that your pipeline reflects your team’s engineering culture—whether that’s strict gating or modern, PR-based visual review.

The post Engineering a Playwright-Native Developer Experience: One Flag, Three Strategies appeared first on AI-Powered End-to-End Testing | Applitools.

TL;DR

• Generative AI is highly effective for creating tests, data, and analysis, but execution has different requirements.
• Test execution demands repeatability, determinism, and explainable failures.
• Probabilistic systems, including LLMs, introduce variability that leads to flaky tests and loss of trust.
• Teams that separate where generative AI helps from where deterministic execution is required scale testing more reliably.

Generative AI has dramatically changed how teams create tests. Requirements can be translated into test cases in seconds. Automation scripts can be bootstrapped with natural language. Test data can be generated on demand.

But many teams are discovering an uncomfortable truth: faster test creation does not automatically lead to more reliable releases.

Execution is where confidence is earned or lost. And test execution demands guarantees that generative AI—including large language models (LLMs)—was never designed to provide.

Where generative AI fits well in testing

Generative AI excels in parts of the testing lifecycle that tolerate variation. These are areas where approximation is acceptable and speed matters more than precision.

Teams are successfully using AI to:

• Generate test cases from requirements
• Assist with unit and integration test authoring
• Create realistic and varied test data
• Summarize test results and surface patterns

In most of these cases, teams are relying on LLMs to generate intent, not to make final execution or release decisions.

These use cases benefit from flexibility. Minor differences in output rarely introduce risk, and human review is often part of the workflow.

The challenge emerges when that same probabilistic behavior is extended into execution.

Why test execution is fundamentally different

Test execution is not a creative task. It is a verification task.

Execution requires:

• The same test to behave the same way, run after run
• Assertions that are precise and stable
• Failures that can be reproduced and diagnosed
• Outcomes that can be explained clearly to stakeholders

Generative AI systems—particularly LLMs—are probabilistic by design. That variability is useful for exploration and generation, but it works against the repeatability and determinism execution depends on.

As AI accelerates development, repeatability becomes more important than intelligence in test execution.

How probabilistic execution creates real problems

When probabilistic systems are used to drive execution, teams often encounter the same failure modes:

• Tests that pass one run and fail the next without code changes
• Assertions that subtly change or disappear
• Longer debugging cycles because failures can’t be reproduced
• Rising compute costs from repeated executions
• Engineers losing confidence in automation results

When failures aren’t repeatable, teams stop trusting their tests—and that’s when automation becomes a bottleneck instead of a benefit.

– Shaping Your 2026 Testing Strategy

Once trust erodes, teams compensate. Manual validation creeps back in. Releases slow down. Automation becomes something teams work around rather than rely on.

Execution amplifies risk: security, governance, and explainability

Execution is also where risk concentrates.

When AI systems drive test execution, they may:

• Send application context externally
• Make decisions that can’t be fully explained
• Produce outcomes that are difficult to audit

These concerns are most visible in regulated and high-risk environments, but they apply broadly. Any team responsible for production releases needs to be able to explain why a test failed—or why a release was approved.

Reliable execution is not just a technical concern. It’s a governance concern.

Why deterministic execution matters at scale

Deterministic systems behave predictably. Given the same inputs, they produce the same outcomes.

In test execution, this enables:

• Reliable failure reproduction
• Faster root cause analysis
• Lower maintenance overhead
• Clear audit trails
• Reduced noise in pipelines

What test execution demands is not intelligence, but guarantees: the same inputs producing the same outcomes, every time.

Reliable test execution depends on determinism, not creativity.

Rethinking AI’s role in execution

The goal is not to abandon generative AI. It’s to use it where it fits.

Effective teams are separating responsibilities:

• Generative AI for creation, exploration, and analysis
• Deterministic systems for execution and verification

This separation allows teams to move quickly without sacrificing confidence.

What this means for engineering and QE teams

As AI becomes more deeply embedded in testing workflows, the key decision is no longer whether to use AI—but where.

Teams that succeed will:

• Accept variability where it’s safe
• Demand determinism where decisions are made
• Measure success by signal quality, not test count
• Optimize for trust before speed

The biggest risk in AI-driven testing isn’t lack of automation—it’s lack of trust.

Choosing confidence over convenience

Generative AI has changed how tests are created. It should not change the standards by which tests are trusted.

Execution is where reliability matters most. Teams that recognize this distinction will scale testing with confidence, even as AI continues to reshape software development.

Watch Shaping Your 2026 Testing Strategy now.

The post What Test Execution Demands That Generative AI Can’t Guarantee appeared first on AI-Powered End-to-End Testing | Applitools.

TL;DR

• Autonomous testing is maturing quickly, but regulated organizations must evaluate platforms through the lens of traceability, auditability, and control.
• Forrester’s Autonomous Testing Platforms Landscape, Q3 2025 shows that the real differentiators now are explainability, risk-based orchestration, and AI governance—not just automation speed.
• Use this checklist to choose a platform that accelerates delivery while protecting oversight.

Download Forrester’s full report for detailed market insights

Rethinking Autonomy for Regulated Teams

With hundreds of tools now promising “AI-driven automation,” sorting true autonomy from clever scripting has become increasingly difficult. This matters even more for regulated teams planning their 2026 quality strategy. Speed is no longer the only concern. Proof, traceability, and controlled execution are now essential.

Forrester’s recent analysis highlights a market shifting from test automation to AI-augmented and agentic systems that generate, maintain, and execute tests under human supervision. The key question for regulated buyers is not whether autonomy will help, but whether the platform provides clear governance around how that autonomy operates.

Use this checklist to evaluate solutions with the guardrails required for safety-critical or compliance-heavy environments.

Core Capabilities Every Autonomous Testing Platform Should Provide

These capabilities form the baseline for operating safely and efficiently in regulated sectors.

Plain-language test authoring and execution
Non-technical reviewers should contribute without adding risk. Natural-language authoring and guardrails make collaboration safe and auditable.

Transparent AI actions
Every generated or changed step must be reviewable. No black-box maintenance. No silent updates.

Evidence management and auditability
Exportable logs, change histories, and evidence packs should support internal and external audits without manual rework.

Role-based control and gated approvals
Automation should accelerate work, but never bypass required compliance workflows.

Adaptive, governed maintenance
Self-healing is useful only when changes are traceable and reversible. Regulated teams need adaptive maintenance under human oversight.

If a platform lacks any of these essentials, it’s not built for environments where documentation and control are mandatory.

Where Advanced Platforms Differentiate

Once the fundamentals are covered, regulated organizations should look at the capabilities that separate mature autonomous solutions from those still catching up.

Intent-based visual and experience validation
Pixel comparison is brittle. Intent-driven validation ensures the interface appears correct, accessible, and compliant across devices and browsers.

Governance dashboards
AI actions, risk coverage, and test triggers should be visible and easy to trace for auditors and managers.

Actionable analytics and reporting
Evidence should turn into insights that support risk management, release approvals, and executive reporting.

Risk-based orchestration
Platforms should prioritize tests based on business criticality, change impact, and historical issues—not just run everything in bulk.

Applying Autonomous Testing in Regulated Workflows

Organizations across healthcare, life sciences, financial services, and other regulated industries are already adopting autonomous testing—but always with governance in place.

In the pharmaceutical sector, EVERSANA INTOUCH takes a hybrid approach, combining Applitools Eyes for Visual AI validation with Applitools Autonomous for intelligent test generation. This end-to-end strategy ensures quality products, supports compliance-ready evidence, reduces maintenance, and provides end-to-end coverage across complex workflows—all while keeping human reviewers in charge. Read the EVERSANA INTOUCH case study.

These hybrid models show how autonomy can increase coverage and speed without loosening control.

Applying the Checklist to Your Evaluation Process

Use this framework when comparing platforms side by side:

• Map your highest-risk business journeys. Focus on areas tied to compliance, customer safety, or financial impact.
• Prioritize transparency. Ensure the platform shows why AI takes each action and allows review before changes go live.
• Assess evidence and governance. Exportable results, audit-ready logs, and approval gates are non-negotiable.
• Evaluate adaptability. Autonomous maintenance should reduce manual effort but still operate inside defined boundaries.

• Reassess regularly. The market is moving fast. Capabilities that seem advanced today will become baseline expectations.

Choosing with Confidence

Autonomous testing is reaching maturity, but regulated organizations need more than speed—they need governance, visibility, and trust. Forrester’s research confirms that platforms built with explainability and risk alignment at the center are the ones best suited for compliance-driven teams.

Use Forrester’s analysis and this checklist to guide your next evaluation and choose an autonomous testing solution that accelerates both delivery and confidence. Download the Autonomous Testing Platforms Landscape, Q3 2025 report.

The post Buyer’s Checklist for Autonomous Testing in Regulated Environments appeared first on AI-Powered End-to-End Testing | Applitools.

Why Test Maintenance Breaks at Scale

Test maintenance at scale slows releases. Teams that rely on coded assertions spend more time updating tests than improving coverage. Brittle locators, environment drift, and false positives all add up—turning automation into a maintenance cycle.

Neglecting maintenance is like skipping car care: small issues snowball into costly downtime. A smarter approach replaces manual review and locator-based scripts with automated, visual validation that adapts as your UI evolves.

How Visual AI Delivers Test Maintenance at Scale

Visual AI replaces dozens of coded assertions with a single checkpoint that mimics how humans see. It validates full UI states, detecting layout shifts, missing elements, and text overlaps automatically.

By consolidating validations into one Visual AI check, teams cut review time, reduce false positives, and gain faster feedback cycles.

Scale Reviews with Ultrafast Grid and Grouping

Running tests one browser at a time no longer scales. The Applitools Ultrafast Grid executes a single test once, then validates results across every browser and device combination in parallel.

Batching and grouping features make reviews equally efficient—approve or reject similar changes across entire runs in just a few clicks.

How it works

• Replace assertions with one visual checkpoint
• Run once across all browsers and devices
• Batch results for unified review
• Approve or reject in bulk
• Tune match levels for dynamic content

Together, these capabilities eliminate redundant effort and make large-scale testing faster to maintain.

Customer Results: 78% Less Maintenance

Teams that adopt this approach see measurable ROI. At Peloton, replacing a legacy visual testing tool with Applitools Visual AI produced a 78% reduction in maintenance time and saved about 130 hours per month.

With dynamic leaderboards, live data, and responsive layouts across web and native mobile, Peloton maintains quality at scale without expanding test overhead.

Three Features That Change Maintenance

“Ultrafast Grid, Visual AI match levels, and bulk grouping—those three change the game.”

Mike Millgate, Smarter Test Maintenance at Scale

These three deliver flexible validation, fast execution, and effortless maintenance. Each removes manual steps and accelerates the feedback loop that keeps releases reliable.

Smarter Maintenance for Modern Teams

Smarter test maintenance isn’t about writing more code—it’s about automating intelligently. Visual AI reduces flakiness, speeds reviews, and scales across devices and environments.

To see what’s next, explore Applitools Eyes 10.22, featuring faster review cycles, new Storybook and Figma integrations, and even shorter feedback loops for test maintenance at scale.

The post Test Maintenance at Scale: How Visual AI Cuts Review Time and Flakiness appeared first on AI-Powered End-to-End Testing | Applitools.

Have you ever encountered a situation where you try to take a screenshot, but instead of the beautifully well-crafted UI, all you’ve got is an image of a spinner/skeleton/loading screen? Handling animations and loading artifacts in visual testing can be daunting.

Don’t worry – it can happen to anyone, and we’re not here to judge you

One of the SDK engineers here at Applitools, Noam, breaks this down into a hands-on tutorial, hoping it will help you get a better understanding of the industry’s best practices around visual testing of rich and dynamic UI experiences.

Let’s dive right in!

Framework Native Solutions

Most frameworks already have different mechanisms to handle animations and loading artifacts. Keeping things simple is often the best way to achieve code stability and maintainability. Using your framework’s built-in tools would most often be the best approach.

For example:

Playwright JS

// Playwright: wait for spinner to be removed
await page.waitForSelector('.spinner', { state: 'detached' });
await eyes.check()

Cypress

// Cypress: wait for spinner to not exist
cy.get('.spinner').should('not.exist'); 
cy.eyesCheck()

Selenium JS

// Selenium: wait for spinner to be invisible
const spinnerElements = await driver.findElements(By.css('.spinner'));
if (spinnerElements.length) {
  await driver.wait(until.elementIsNotVisible(spinnerElements[0]), 5000);
}
await eyes.check()

A Common Pitfall

Even if the UI appears visually unchanged, frontend frameworks like React, Vue, and Angular may re-render elements under the hood. This can lead to stale element references, especially when capturing regions right after a DOM change.

Consider the following example:

cy.get('.main').then($el => {
  cy.get('.spinner').should('not.exist'); // spinner disappears after main was located

  cy.eyesCheckWindow({
    tag: 'main',
    target: 'region',
    element: $el, // stale reference if .main was replaced
  });
});

1. First, Cypress locates .main
2. Then, Cypress waits for the spinner to disappear
3. This example would fail (even if the new element has the exact same properties) if the main element is replaced by another element

How to avoid that?

When possible (e.g., Playwright), it’s preferred that you use locators instead of selectors. If you can’t, it’s better if you use selectors instead of DOM references (element: ‘.main’).

Videos, CSS Animations, GIFs

There are many techniques to eliminate other types of dynamic behaviour in web pages. Playwright, for example, provides a Clock API that allows pausing JavaScript time-related events (including JS-driven animations). It’s also possible to install custom CSS snippets to pause and reset CSS-related animations. Other JS specialized crafted snippets would be required for resetting GIFs, videos, and so on – you get the idea.

This never-ending cat-and-mouse game can be prevented by using Applitools Ultrafast Grid (UFG). Instead of rendering web pages on locally executed browsers, the UFG team maintains specialized logics and fine-tuned commands that ensure a stable and consistent rendering experience. While UFG offers more than just rendering stability, it’s worth noting that classic screenshots can still achieve stable results. UFG just makes it easier!

Algo-Based Solutions

If you intentionally want to capture dynamic content (e.g., animations, changes), a smarter strategy is to embrace that variability and use smart matching algorithms to compare just what you need, like those found in Applitools Eyes.

Any match level can be used for the entire screenshot or specific regions of the screen. Read more in the Match Level Best Practices tutorial. For example, algorithms like the Layout match level can drastically improve your experience with localization testing.

The waitBeforeCapture Setting

Performing wait operations can become more complicated when:

1. Testing with no-code visual testing SDKs (e.g eyes-storybook)
2. Testing with advanced Eyes features like lazyLoading and layoutBreakpoints

The waitBeforeCapture setting was invented for these types of use cases (and a few others).

This setting can receive three types of arguments:

1. Milliseconds – the simplest approach. While it’s not always the most innovative or sophisticated pattern, in many cases, it “does the trick.” In general, waiting for explicit timeouts during tests is not recommended. However, when compared to clock manipulations and code injections, sometimes the simplicity and stability is worth the longer run-time.
2. Selector – when we’re waiting for something to appear, most SDKs support passing a selector, and Applitools Eyes will automatically wait for an element that matches this selector to appear in the web page.
3. Custom function – see code example

// eyes-storybook
  waitBeforeCapture: async () => {
    while (document.querySelector('.spinner')) {
      await new Promise((resolve) => setTimeout(resolve, 100))
    }
    return true;
  }

// eyes-playwright
await eyes.check({
  name: 'my-step',
  async waitBeforeCapture() {
    await page.locator('.spinner').waitFor({state: 'hidden'})
  },
})

The waitBeforeCapture setting can be defined in your applitools.config file, in your eyes.check settings, using the Target settings builder, and in other similar places. Please refer to the documentation of the specific SDK you’re using for concrete examples.

Storybook Play Functions

A nice eyes-storybook-specific trick to achieve a desired rendering state would be a Storybook Play Function.

Applitools Eyes will run your play functions and wait for them to finish before capturing anything on the screen. Use Play Functions to navigate the story to an interesting state and wait for the story to be stable inside the play function to help Eyes understand what the best time is to capture the screenshot.

Applitools is Here to Help

We hope you’ve found this article interesting, and maybe it solved some of the most common visual testing issues you may have encountered. Go ahead and try these examples out for free with Applitools Eyes.

However, if something isn’t clear or if you’d like advice regarding the best way to incorporate visual testing into your organization, please don’t hesitate to reach out to our experts! Testing is our passion, and we’re here to help.

Quick Answers

The post Handling Animations and Loading Artifacts in Visual Testing appeared first on AI-Powered End-to-End Testing | Applitools.

You’ve got your unit tests. Your end-to-end flows. Maybe even 100% code coverage. But bugs still slip through.

That’s because full code coverage doesn’t guarantee full test coverage. Visual glitches, browser inconsistencies, and content drift often escape traditional automation — and they’re exactly the kinds of issues your users notice first.

In The Coverage Overlook, the kickoff session of our Testing Your Way: Code & No-Code Journeys webinar series, we explored five critical coverage gaps most teams miss — and how to close them with AI-powered visual testing and no-code tools.

1. Visual and Layout Bugs

Code-based assertions won’t catch when an element shifts, disappears, or overlaps. That’s where Visual AI steps in.

By analyzing the rendered UI — not just the DOM — Visual AI identifies layout issues, missing images, overlapping text, and subtle visual defects with a single line of code (or none at all).

“Visual AI can instantly catch layout shifts, missing elements, and new text that coded assertions would miss — all without the maintenance burden of custom locators.”
— Tim Hinds, Applitools

2. Cross-Browser and Device Inconsistencies

Most test suites default to Chrome. But real users span dozens of devices and browsers.

Visual AI tools like Applitools Eyes can validate your app across multiple browsers and screen sizes in parallel — using a single test run. No custom scripting required.

3. Dynamic Content Variations

Personalized content, A/B tests, and location-based content are tough to verify with scripted tests alone.

Visual AI combined with flexible match algorithms can confirm layout structure while ignoring safe visual differences — helping your team catch what matters, without writing exceptions for every variant.

4. Lower-Priority Flows and Pages

Teams tend to focus their test coverage on critical flows — like checkout or login — and leave lower-traffic pages untested.

No-code tools like Applitools Autonomous make it easy to cover the rest. A built-in crawler can scan your site and establish visual baselines across dozens (or hundreds) of pages — all without writing a single test script.

5. Accessibility Gaps

Code coverage can’t catch color contrast failures, missing labels, or overlapping elements that make your UI inaccessible.

Visual AI can. And with upcoming enforcement of the European Accessibility Act, now is the time to start catching these issues early.

Watch the Full Session On-Demand: Code & No-Code Journeys: The Coverage Overlook

Closing the Gap

Code coverage still has value — but modern teams are shifting toward user-centered test coverage.

As shared in the session, teams like Eversana are combining code-based, no-code, and visual testing strategies to expand coverage, accelerate feedback, and reduce risk. With this blended approach, they’ve achieved:

• 65% reduction in regression testing time
• 750+ hours saved per month
• 90% test stability
• A unified testing culture across manual testers, developers, and QA

What’s Next in the Series?

The journey continues with The Maintenance Shortcut, where we explore how teams are reducing flaky tests, eliminating brittle locators, and cutting test maintenance with Visual AI and Autonomous.

The post Think You Have Full Test Coverage? Here Are 5 Gaps Most Teams Miss appeared first on AI-Powered End-to-End Testing | Applitools.

As a Salesforce tester, if you’re unfamiliar with visual testing—don’t worry, you’re in the right place! This blog will walk you through everything from the basics of visual testing to practical Salesforce-specific examples. You’ll learn how to catch visual bugs that can break user trust and impact experience. By the end, you’ll be confident in applying visual testing to your Salesforce QA projects.

Let’s begin.

Real Examples of Visual Bugs in Salesforce

Consider this Scenario

You are working on a team and have just deployed a great feature. The developer is happy with how it turned out, and the project manager is satisfied with the delivery. As a QA, you gave the green signal after testing—everything looked perfect. And the best part? The entire process went smoothly, without any escalations or last-minute issues.

That’s what successful teamwork looks like: the developer built it right the first time, the tester confirmed, and the client exclaimed, ‘This is great!’ It’s rare that things go so smoothly every single time.

Is everything really this easy? In practice, the real world likes to surprise us…

A Real World Scenario

The deployment happened on Friday, and on Monday morning, you and your team received an email. In that email, the surprises begin to unfold. One by one, the bug reports start coming in.

Someone points out a couple of issues:

The first issue: the “Add to Cart” and “Configure” buttons overlap in the Salesforce CPQ cart, making it difficult for users to interact with them properly.

The second issue: a user reports that transparent PNG images do not display correctly on mobile devices when the ‘Optimize Images for Mobile’ setting is enabled in Communities.

What looked like a smooth and successful deployment is now showing signs of trouble.

Why Salesforce QA Teams Should Prioritize Visual Testing

As a Salesforce tester, visual testing means checking how the UI looks and behaves—not just whether it works.

You’re not just checking if buttons work or forms get submitted. As a Salesforce tester, you’re also making sure:

• The layout looks good on both desktop and mobile
• Fields show up correctly based on user roles and permissions
• Lightning components display well in different browsers
• Page layouts and themes don’t break the design
• Third-party apps don’t affect the visual appearance
• What you saw in UAT looks exactly the same in Production

This is especially crucial in Salesforce, where small changes in configuration or access can lead to big differences in what users see.

We all know that Salesforce is a robust platform where a lot of emphasis is placed on configuration, customization, personalization, and a user-centric approach. Specifically, when we talk about Lightning Components and Experience Cloud, the UI can vary based on several criteria, such as:

• Profile permissions
• Screen resolution
• Browser type
• And many other factors…

As a Salesforce QA team member, you may write and update many test cases, and everything might seem to be running smoothly in terms of functionality. However, unless you check how it actually renders, you’re missing a huge part of the user experience.

At this point, we can’t afford to ignore visual testing or say we’ll deal with it later. It has become a necessity to ensure usability.

How to Implement Visual Testing in Salesforce Projects

1. It all starts with awareness and education—helping your engineering team build the mindset to treat visual diffs just like code diffs, reviewing and approving them with the same seriousness.
2. Start small by choosing high-impact pages like the CPQ cart, lead detail, and dashboards. These are user-critical areas where even minor visual issues can hurt usability and trust.
3. Focus on consistently monitoring visual test results with every release and pull request. This helps catch unexpected UI changes early and maintain visual consistency.
4. Make visual testing part of your testing culture—ensure your team treats visual bugs with the same importance as functional bugs. It might be a bit challenging initially, but once this habit is established, it will bring strong results in the long run.
5. Take clear screenshots of important pages to set a visual starting point. Later, these baseline screenshots are used to spot any unexpected UI changes during testing.

How Visual Testing Improves UI Consistency in Salesforce

Here are some hard-learned reasons why Salesforce QA teams must take visual testing seriously:

• Brand Image and Customer Confidence: In Experience Cloud or partner portals, maintaining visual consistency is key to your brand’s identity. A broken UI leads to a broken reputation—what users see is what they’ll believe.
• Totally Unpredictable UI: You’re not just testing code. You’re testing flows, field visibility, and permission-based rendering, all of which affect the layout. With three releases every year, each bringing new updates and sometimes removing existing features, the UI can become unpredictable.
• High Deployment Frequency: With frequent changes in CI/CD pipelines, even small style updates can lead to visual mismatches. In real life, you might notice that something looks one way in UAT but appears differently in Production after deployment.
• Functional Tests Don’t Catch UI Issues: All your test scripts have passed—congratulations! But the point is, a poor layout can still disrupt the user experience. That’s exactly when visual testing comes into the picture.
• UI Changes Based on User Roles: Different users may see different screens or fields—visual testing helps make sure everything looks right for everyone.

Valuable Takeaways for Salesforce QA Teams

Whether you’re testing Sales Cloud, Service Cloud, or an extensively customized Experience Cloud portal, these key principles apply:

• Start Small with High-Impact Pages
  Begin with pages that matter most—such as CPQ carts, lead detail views, or dashboards. These are user-critical zones where even minor UI issues can impact adoption.
• Create Visual Baselines
  Take clear screenshots of important pages during UAT. Use them as reference points for future deployments to catch unexpected changes.
• Automate Screenshot Comparisons
  Don’t rely on manual ‘look and feel’ reviews. Use tools like Applitools to automate visual checks, test across browsers and devices, and ensure UI integrity on every release.
• Involve the Whole Team
  Encourage developers, testers, and product owners to review visual diffs during pull requests. It reinforces a culture where UI quality is everyone’s responsibility.

Don’t underestimate visual appeal as part of user experience—in Salesforce, a flawless UI through visual testing can be the difference between closing or losing a deal.

Wrapping Up: The Business Case for Visual Testing in Salesforce

Visual testing is super helpful when it comes to making sure your Salesforce app not only works well but also looks right on different browsers, devices, and for different users. 

In Salesforce, things like profile permissions, Lightning page setups, and screen sizes can change how components appear. That’s why visual testing is important—it helps you catch UI issues early.

It might seem tricky at first, but Salesforce testing with Applitools makes it easier. This blog gave you a basic idea of why visual testing matters to Salesforce QA teams and how you can get started. Now you’re ready to explore more and improve your testing process.

The post Why Visual Testing is Crucial for Salesforce QA Teams appeared first on AI-Powered End-to-End Testing | Applitools.

AI is transforming software testing—but without clear context, even the smartest models can fall short. The new Model Context Protocol (MCP) aims to solve that problem, and it’s picking up momentum fast. Here’s what QA and development teams need to know—and why it matters right now. If you have questions about how we’re building for the future or how this fits into your testing strategy, let us know—we’d love to talk.

What Is MCP?

MCP, or Model Context Protocol, is an open standard designed to help applications provide AI models with structured context. Think of it as a standardized way for tools and systems to tell an AI assistant what’s going on—who the user is, what they’re doing, and what resources are available.

Anthropic introduced MCP in late 2024, and it’s already being adopted by major players like OpenAI, Microsoft, and testing leaders building next-generation AI workflows. Addy Osmani, an engineering leader at Google, calls MCP “the USB-C of AI integrations,” highlighting its potential to standardize the connection between tools and intelligent agents.

Why Context Matters in AI-Assisted Testing

Large language models (LLMs) are only as good as the context they receive. Without proper inputs, you get generic outputs—or worse, hallucinations. For QA teams using AI to generate tests, interpret failures, or automate user flows, missing context leads to fragile results and wasted time.

MCP helps solve this by passing structured information to the model: which test framework is in use, what files are open, what code just changed, and more. That means faster, more relevant AI assistance—and more accurate automation.

What MCP Enables in Testing Workflows

MCP makes it easier for tools and AI assistants to share structured context—like which framework is active, what code changed, or what the user is trying to do. That unlocks more accurate test generation, better debugging, and scalable, reusable automation.

It also supports dynamic discovery, so AI systems can find and connect with available tools at runtime—no brittle configs or manual setup required.

As testers ourselves, we take a measured approach to adopting new AI standards like MCP. That means vetting integrations for stability and reliability, so our customers can move fast without sacrificing trust.

Why It’s a Big Deal Now

There are two key reasons to pay attention to MCP today:

First, the standard is taking off. Thought leaders like Angie Jones, Filip Hric, Tariq King, and Addy Osmani are publishing real-world MCP demos and contributing open-source tools. It’s not theoretical anymore—it’s happening.

Second, the stakes are high. As more testing platforms integrate AI (including Applitools Autonomous), the ability to connect tools through open standards like MCP is becoming a competitive differentiator.

How Applitools Fits In

Applitools has long focused on intelligent automation—delivering AI-powered test creation, visual validation, and self-healing across platforms. As open standards like MCP emerge, we’re building on that foundation to extend context-sharing across tools, so teams can:

• Automatically create or update visual and functional tests based on code changes
• Route test context through the pipeline for faster root cause analysis
• Improve AI-generated tests with better accuracy and explainability
  

Security is also critical. As MCP evolves, host-mediated permissions and encrypted communication protocols are being considered by contributors to ensure context is shared safely and responsibly.

At Applitools, we’re building these principles directly into the future of Autonomous and Eyes—and we’d love to walk you through what’s on our roadmap. If you’re already an Applitools customer, reach out to your account team to schedule a preview conversation. If you’re not already using Applitools, schedule time with one of our testing specialists—we’re here to help.

The post MCP: What It Is and Why It Matters for AI in Software Testing appeared first on AI-Powered End-to-End Testing | Applitools.

If you’ve already explored how AI-powered, no-code test automation tools can expand who contributes to testing, the next question is: how do you choose the right AI approach for your broader strategy?

Teams today face more pressure than ever to deliver faster without compromising quality. Traditional test automation can’t keep pace—it’s often brittle, siloed, and difficult to scale across teams.

AI-powered testing offers new ways to accelerate coverage, improve stability, and reduce manual effort. But not all AI is created equal. Understanding the differences between AI-assisted, AI-augmented, and autonomous testing models can help you adopt the right tools at the right time—with the right expectations.

Understanding the AI Testing Landscape

AI is showing up everywhere in the testing conversation, but it’s not always clear what type of AI is in play—or how much human involvement is still required. Here’s a breakdown:

AI-assisted testing

These tools support engineers during test creation. Think: autocomplete, code suggestions, or debugging help. They speed up test authoring but still rely on someone writing the test manually.

AI-augmented testing

These systems go further by analyzing existing test repositories, usage data, or logs to identify missing coverage or redundant cases. The AI assists strategically, but the tester still has the final say.

Autonomous testing

This model allows AI to execute test scenarios based on higher-level inputs—like a test goal or an intent. With access to the application, past test data, and usage patterns, it can decide what to test and how. Human oversight is still essential, but the AI drives more of the process.

Each model – assisted, augmented, or autonomous – shapes who can contribute to testing and how much oversight is needed. Choosing the right mix ensures your entire team can move faster without sacrificing quality.

Solving for Coverage, Speed, and Stability

As testing shifts left—and right—teams need solutions that can handle growing complexity without adding manual effort. AI helps in several key areas.

Reducing Flaky Tests

Flaky tests are a drain on time and confidence. They often result from brittle locators, timing issues, or inconsistent environments.

AI-powered self-healing automatically updates broken selectors when the UI changes, helping teams avoid rework and unnecessary test failures.

Authoring Tests Without Code

AI can also simplify how tests are created. NLP-based test creation, for example, allows users to define actions in plain English or record workflows that are translated into readable steps.

This approach has become one of the most accessible and impactful uses of AI in testing, enabling broader participation—from QA to product to manual testers.

Visual Validation for Real-World UI Testing

Functional scripts may confirm that a button exists—but they can’t always tell if it’s visible, clickable, or correctly placed. Visual AI ensures that tests validate what a user actually sees, not just what’s in the DOM.

This level of intelligence is especially critical for responsive design testing and dynamic layouts.

Choosing an Approach That Fits Your Team

The right AI testing strategy depends on where your team is in its automation journey.

• If you’re accelerating test writing with existing frameworks, AI-assisted tools may be the quickest win.
• If you’re optimizing test coverage and reducing redundancy, AI-augmented systems can help prioritize the right areas to test.
• If you’re expanding test ownership across roles, autonomous testing—especially when paired with no-code NLP creation—offers the scale and accessibility to match.

Many teams benefit from a layered approach, combining all three models across workflows.

And behind the technology, delivery matters. Tools powered by in-house AI models offer faster, more consistent results with greater control over privacy and cost—key factors for scaling in enterprise environments.

What’s Next

AI in testing isn’t about replacing people—it’s about enabling them to do more with less. Whether you’re automating UI tests with NLP, analyzing risk with augmented AI, or building autonomous test flows, the goal is the same: faster releases, better coverage, and fewer late-cycle surprises.

Want to explore how different AI models can work together across your test strategy? Watch the full session on demand and see how teams are applying AI-powered testing models to scale quality without increasing complexity.

The post AI-Powered Testing Strategy: Choosing the Right Approach appeared first on AI-Powered End-to-End Testing | Applitools.

In today’s hyper-competitive environment, efficiency is king. Ensuring quality without slowing down development cycles is a critical priority for organizations looking to stay ahead. Hybrid test automation—combining both coded and no-code tools—has emerged as a game-changer. The smartest organizations are adopting this approach to reduce maintenance, accelerate releases, and empower cross-functional teams.

Applitools customer, Eric Terry, Senior Director of Quality Control at EVERSANA INTOUCH, underscored how a hybrid approach to test automation bridges skill gaps, enhances collaboration, and accelerates time-to-market. This article explores why a dual automation strategy isn’t just an IT initiative—it’s a business imperative.

The Business Risks of Choosing Just One Approach

When organizations lean too heavily on either coded or no-code automation, inefficiencies emerge. Coded automation offers flexibility and customization but demands highly skilled engineers, creating bottlenecks. No-code automation empowers non-developers but may lack depth for complex scenarios.

A hybrid strategy aligns technical capabilities with business needs, ensuring that:

• Routine tasks and UI-driven tests are handled by AI-powered no-code tools like Applitools Autonomous.
• Complex scenarios requiring deep customization leverage coded automation.
• Testing scales across diverse skill levels, unlocking greater efficiency.

Faster Releases, Higher Quality: A Competitive Advantage

Accelerating time-to-market while maintaining quality is a strategic advantage. Companies that integrate both coded and no-code automation realize efficiency gains, including:

• Reduced test maintenance: “We cut test maintenance by 40% by integrating AI-driven no-code automation,” Eric shared.
• Parallel execution: Running tests simultaneously across environments accelerates feedback loops.
• Smarter test selection: AI-powered tools identify the most critical tests, reducing regression cycles by up to 70%.

Collaboration as a Business Driver

Siloed workflows kill efficiency. When manual testers, automation engineers, and developers operate in isolation, knowledge gaps and redundancies increase risk.

Successful hybrid test automation programs:

• Encourage mentorship, where automation engineers guide manual testers.
• Align automated testing efforts with broader business goals.
• Leverage collaborative tools like Azure DevOps and Microsoft Teams for transparency.

Cost Savings: The Overlooked Benefit of Hybrid Automation

Cost efficiency isn’t just about reducing headcount; it’s about maximizing team output. Organizations that embrace a hybrid test automation approach realize:

• Lower hiring costs by enabling manual testers to contribute to automation efforts.
• Higher productivity by freeing developers from routine scripting.
• Broader adoption as business teams leverage no-code tools for non-QA applications, such as UI validation.

“Anytime that you can save some time, it has the potential to that into revenue,” Eric emphasized.

The No-Code Mindset Shift: A Leadership Imperative

Historically, tech leaders viewed no-code solutions as limited. But AI-driven platforms like Applitools are changing the game, allowing teams to scale automation without specialized expertise.

“I think we’ll start to see the uptick,” Eric predicted. “Tools are getting better, and they’re making automation more accessible than ever.”

See first-hand how Applitools can help your teams bridge skill gaps and scale test automation with a free trial.

Next Steps: Implementing a Hybrid Approach in Your Organization

For leaders looking to integrate both coded and no-code automation, consider these steps:

1. Assess your skill gaps – Identify where no-code solutions can bridge inefficiencies.
2. Start small, then scale – Pilot no-code automation for repetitive workflows.
3. Foster a whole-team quality mindset – Align teams around a shared automation vision.
4. Leverage AI-powered tools – Reduce maintenance while increasing test accuracy.

Future-Proof Your Testing Strategy

In the words of W. Edwards Deming, “It is not necessary to change. Survival is not mandatory.” Organizations that resist automation evolution risk falling behind. By strategically integrating both coded and no-code automation, businesses position themselves for faster innovation, higher quality, and stronger collaboration.

Hear more of EVERSANA’s story by watching Code or No-Code Tests? Why Top Teams Choose Both.

The post Bridging the Gap: Why Businesses Thrive with Hybrid Test Automation appeared first on AI-Powered End-to-End Testing | Applitools.

Test automation has traditionally lived in the hands of a few specialists—those with the right coding skills, framework knowledge, and time to maintain complex test suites. But software quality touches every part of the delivery process, from product to engineering to QA.

Modern no-code test automation tools are shifting that dynamic. These AI-powered platforms enable teams across roles to create, run, and maintain automated tests—without writing code. And they’re doing it without sacrificing speed, accuracy, or scale.

Here’s how these tools work, what they solve, and why they’re reshaping the way teams approach software quality.

Breaking the Bottlenecks of Traditional Automation

Traditional test automation frameworks come with steep requirements: deep technical skills, time-consuming setup, and scripts that only a few team members can decipher. This creates bottlenecks. When product owners or manual testers can’t contribute, test coverage shrinks—and feedback loops slow down.

No-code test automation tools address this challenge by allowing users to write tests in plain language. Instead of scripting every action, they can describe intent:

“Enter email in login form.”
“Click the primary button.”

This approach makes test cases easier to read, faster to debug, and simpler to hand off between roles.

From Recorded Actions to Readable Test Steps

Most no-code platforms offer more than just simplified language—they streamline how tests are created in the first place. With action recording, testers interact with the app as a user would. Behind the scenes, the tool converts those actions into plain-English test steps using AI and natural language processing.

This drastically reduces authoring time. And since the resulting steps are readable by anyone on the team, debugging and collaboration get a lot easier.

Compared to traditional scripting, this is a faster, clearer, and more inclusive way to build test coverage.

Expanding Who Can Contribute to Test Automation

When test authoring isn’t limited to engineers, more of the team can contribute to quality. That doesn’t just speed things up—it also improves collaboration and visibility.

• Manual testers move from documentation to execution without needing to code.
• QA engineers delegate simpler test flows and focus on complex or edge cases.
• Product owners and business analysts define expected behaviors directly in test interfaces.
• Developers get fast, readable test results that don’t require decoding selectors or scanning logs.

This shift improves velocity while reducing dependencies on any one person or team.

AI Behind the Simplicity: Powering Stability at Scale

The best no-code test automation tools go beyond accessibility—they’re backed by intelligent automation that’s production-ready.

• Self-healing fixes broken locators automatically, even when UI structure changes.
• Visual AI ensures the UI looks right—not just that elements exist in the DOM.
• Root cause analysis explains test failures clearly, saving hours of manual debugging.

These capabilities give teams confidence that their tests will work reliably across browsers, devices, and environments. And when the platform is powered by in-house AI (not third-party APIs), it ensures greater speed, privacy, and control.

Scaling Quality, Not Just Test Automation

No-code test automation tools don’t eliminate testers—they empower them. When everyone can contribute to testing, teams increase their coverage, accelerate release cycles, and reduce time spent chasing down brittle scripts.

What used to take hours of setup or deep technical expertise can now be achieved through a browser session and plain-English instructions. That’s the power of no-code—and the intelligence of modern AI testing tools.

Want to see how no-code test automation works in practice? Watch the full session on-demand and explore how teams are scaling test coverage with AI-powered tools designed for speed, stability, and collaboration.

The post No-Code, No Problem: How AI Testing Tools Expand Test Automation Across Teams appeared first on AI-Powered End-to-End Testing | Applitools.

For many QA teams, automation presents a challenge: how do you scale efficiently when team members have different levels of coding expertise?

Eric Terry, Senior Director of Quality Control at EVERSANA INTOUCH, shared how his team successfully adopted a hybrid automation approach—leveraging both coded and no-code automation to bridge skill gaps, improve test efficiency, and enhance collaboration.

For teams considering Applitools Autonomous, Eric’s journey offers a real-world example of how AI-powered, no-code automation can accelerate testing while making automation accessible to a broader team.

The Challenge: Skill Gaps in Testing Teams

QA teams often include a mix of experienced developers and manual testers with limited coding experience. This gap can create inefficiencies and limit test coverage.

Common challenges QA managers face:

• Manual testers want to contribute to automation but lack programming skills.
• Automation engineers spend too much time maintaining scripts rather than innovating test strategies.

Inconsistent automation practices lead to knowledge silos and increased maintenance overhead.

The Solution: An AI-Powered Hybrid Approach to Coded and No-Code Automation

Eric’s team adopted a hybrid strategy that leverages both coded and no-code automation tools, ensuring that:

• AI-powered no-code tools (like Applitools Autonomous) allow manual testers to create automated tests with minimal coding.
• Coded automation remains essential for complex test scenarios requiring deep customization.
• Teams focus on collaboration, mentorship, and upskilling rather than forcing a single approach.

Eric’s team reduced test maintenance by 40% by integrating AI-driven no-code automation while keeping developers focused on high-value coding tasks.

The Benefits of an Autonomous-First Approach

One of the biggest breakthroughs for Eric’s team was prioritizing Autonomous-first testing for repetitive and UI-driven test cases. This led to:

• Faster onboarding for manual testers wanting to contribute to automation.
• Significant reduction in test maintenance, as AI-driven automation adapted to UI changes.
• More streamlined workflows, with non-developers actively participating in automation.

Key benefits of AI-powered no-code tools:

• Faster test creation for repetitive workflows.
• Reduction in script maintenance by up to 60%.
• Empowering manual testers to contribute without coding expertise.
• Accelerated test cycles by running automated tests in parallel.

Real-World Example: EVERSANA’s No-Code Automation Success

• Challenge: The team had a mix of highly technical engineers and manual testers who wanted to contribute to automation but lacked coding skills.
• Solution: They implemented a no-code-first strategy, using Applitools Autonomous to allow non-coders to automate repetitive UI tests.
• Results: Faster test execution, reduced manual effort, and a more collaborative approach to QA.

Want to see how Applitools Autonomous can help your team bridge your skill gaps to scale test automation? Try a free trial today.

How to Get Started: Lessons from Eric Terry’s Team

For QA teams considering Applitools Autonomous, Eric’s experience provides a clear roadmap for success in scaling coded and no-code automation to boost test efficiency. His key recommendations include:

1. Encourage cross-functional collaboration – Build mentorship programs where automation engineers support manual testers.
2. Adopt an Autonomous-first mindset – Automate simple workflows first before investing time in complex scripting.
3. Leverage AI-powered tools – Use visual testing and self-healing automation to minimize maintenance effort.
4. Align automation efforts with business goals – Ensure test automation supports faster releases and higher product quality.

Learn more by watching Code or No-Code Tests? Why Top Teams Choose Both

The post How an Applitools Customer Scaled QA Automation by Bridging the Skill Gap appeared first on AI-Powered End-to-End Testing | Applitools.