Skip to main content
E-commerceAutomation

Recorded UI scripts broke after every redesign, and the rewrite never finished

A storefront moved to web components and the selector-based suite started failing every sprint. Here is how the automation team carried its tests across instead of rewriting them, and kept a way out.

Scenario: A QA automation team maintaining a storefront regression suite

Problem

A move to web components, icon-only buttons and an embedded payment frame broke years of Selenium scripts, sprint after sprint.

Solution

Import the existing suite, run it on an engine that reads the live page, repair in one place, and keep an exit as real code.

Capabilities usedImport from an existing repositoryWeb UI automationShadow DOM, SVG icons and iframesSelf-healing + Step RepairExport runnable automation code

The problem

The storefront was rebuilt on web components, with icon-only buttons for cart and wishlist and a payment form inside an iframe. The automation team's Selenium suite held years of knowledge, but each release broke more of it, and sprint time went on repairing selectors instead of adding coverage.

  • Selectors that passed yesterday failed after a layout or styling change.
  • Controls inside web components and the payment iframe needed custom code, case by case.
  • Icon-only buttons had no visible text to target.
  • Moving to a new tool looked like starting from zero, with a new lock-in at the end of it.

The solution

The aim was to keep what the team already knew about the storefront and stop paying for the same breakage twice.

  1. Bring the existing suite across

    Import from an existing repository

    QAEverest reads the GitHub, GitLab or Bitbucket repository that holds the Playwright, Cypress, Selenium, pytest, JUnit or Cucumber tests, turns each test into a readable test case for review, and recreates the folder and suite structure.

  2. Run against the live page

    Web UI automation

    Each step is resolved against the page as it runs. A selector remembered from an earlier run is only a hint, checked before it is used; if it no longer fits the element the step names, the element is found again from the page itself.

  3. Handle the modern front end from plain steps

    Shadow DOM, SVG icons and iframes

    Controls inside web components are found from the label on screen. Icon-only buttons are found by their accessible label, SVG title or icon name, and clicked on the control that owns the icon. Inside the payment iframe every action stays in the right frame, even when two frames share an id.

  4. Repair once, not every run

    Self-healing + Step Repair

    When an element has moved, the healing agent finds it and records the heal, so the change is visible rather than hidden behind green. A failed step has one Step Repair button with four remedies — reword it, point at the right element, wait for the page, or accept with a note — and the repair is saved for the next run.

  5. Keep an exit

    Export runnable automation code

    After a run, the same journey downloads as Playwright (TypeScript or Python), Selenium (Java) or Cypress code built from the locators the run actually resolved. Where a framework has no equivalent, the code says so in a comment.

What changes

  • The team's existing test knowledge carried over instead of being rewritten.
  • A layout change no longer starts a selector hunt; when the engine re-finds an element, the heal is on record for review.
  • Web UI suites can run two, three or four test cases at a time, each in its own browser, at the same credit cost.
  • Lock-in stops being a reason to wait: the team can leave with real code whenever it chooses.

Read more

Facing a problem like this?

Bring one of your own stories, suites or release questions to a demo and we will walk through it in the product with your QA team.

Book a demo Start free

More case studies

B2B SaaSScenario

A nightly suite that was red so often, its results stopped being read

Problem

The same few tests failed most nights, real regressions hid among them, and a screenshot showed that a step failed but not why.

Solution

Flaky tests separated from regressions, failures replayed with an AI root cause, and seeded defects that show what the suite really catches.

Read the case study
PaymentsScenario

The API returned 200, but did the payment actually reach the database?

Problem

API tests checked status codes only; tokens were copied between requests by hand and the ledger row was checked separately in a SQL client.

Solution

Chained API requests, read-only database steps in the same test case, and generated integration and database cases for review.

Read the case study