The settings page just got redesigned. The inline form became a modal. The "Save" button moved to a footer. Three navigation tabs collapsed into a dropdown menu. Your product improved. Your tests broke.
This is the moment that defines your QA automation approach. In traditional testing tools, this scenario means manual fixes, updated selectors, and an afternoon of maintenance work. In JustQA, the tests adapt automatically. The UI changed. The tests survived.
This article shows exactly how that works — the concrete mechanics of intent-based healing and the difference between regression that breaks with every release and regression that updates itself.
The Traditional Response to UI Changes
When a UI change breaks traditional automation, the typical workflow looks like this: the test suite runs after deployment, failures appear across multiple test cases, someone investigates each failure to determine if it's a real bug or just a layout change, broken selectors get manually updated, the suite runs again, and the cycle repeats until everything passes.
The problem is not that this workflow is wrong. The problem is that it does not scale. When your product changes weekly or daily, this maintenance overhead becomes the largest cost in your QA operation. Teams spend more time fixing tests than expanding coverage.
Most "self-healing" tools try to solve this by rescanning the page and finding elements with similar attributes. That works sometimes. But it fails the moment the user intent behind an action changes, even slightly.
What Traditional Self-Healing Actually Does
Traditional self-healing works at the selector level. When a test fails because a button moved, the tool rescans the DOM, looks for elements with similar text or attributes, picks the closest match, and updates the selector reference.
This approach helps with simple changes like CSS class renames or minor layout shifts. But it breaks down when:
- Multiple elements share the same text but serve different purposes
- The action sequence changes — for example, a one-step flow becomes two steps
- A modal replaces an inline form, changing the interaction context
- Navigation paths are reorganized, requiring different steps to reach the same destination
- Form validation logic changes, altering the expected flow
Selector healing assumes the user journey stays exactly the same. Intent-based healing understands that the journey can change while the goal remains constant.
What Intent-Based Healing Means
Intent-based healing works at the goal level, not the selector level. Instead of asking "where is this button now," JustQA asks "what is this test trying to accomplish, and how does a user accomplish that in the current UI?"
When a settings page gets redesigned, JustQA does not just look for the same "Save" button in a new location. It understands that the test's intent is to update a user profile and confirm the change persisted. It then explores the redesigned interface to find how a user now completes that goal — even if the flow changed significantly.
This is possible because JustQA maintains a semantic understanding of your product. Qitty, the autonomous AI QA agent, continuously learns what each flow is meant to accomplish. When the UI changes, Qitty re-explores the interface, matches the new implementation to the original intent, and updates the test steps automatically.
A Concrete Example: Settings Page Redesign
Here's a real scenario. A SaaS product's settings page had an inline form with fields for display name, email, and notification preferences, plus a "Save Changes" button at the bottom. The test case had three steps: navigate to settings, fill the display name field, and click "Save Changes."
The product team redesigned the page. The inline form became a modal that opens from an "Edit Profile" button. The fields stayed the same, but the save action moved to a modal footer, and there's now a "Cancel" option that wasn't there before.
In traditional automation, this breaks the test completely. The "Save Changes" button no longer exists on the main page. Someone has to manually discover the new flow, rewrite the test steps, and update the selectors.
In JustQA, the test survives automatically. Here's what happens behind the scenes:
- Qitty detects that the test failed after a deployment
- Instead of just looking for the missing button, Qitty re-explores the settings page
- It identifies that the goal "update user profile" now requires opening a modal first
- It maps the old flow to the new flow: navigate to settings → click "Edit Profile" → fill display name in the modal → click "Save" in the modal footer
- The test steps are updated automatically to reflect this new path
- The test runs again and passes — no manual intervention required
The UI changed. The tests survived. That is intent-based healing.
Selector Healing vs Intent Healing
Selector healing asks: "Where did this element go?"
Intent healing asks: "How does a user accomplish this goal now?"
That distinction matters most when the UI change is more than cosmetic. Consider a checkout flow. The original flow had a single-page form with billing address, payment method, and a "Complete Purchase" button. The redesigned flow split this into three steps: billing address on page one, payment method on page two, review on page three, with "Continue" buttons between steps and "Complete Purchase" only on the final page.
Selector healing would fail immediately — the "Complete Purchase" button is no longer on the first page. Intent healing understands the goal is to complete a purchase, re-explores the checkout flow, recognizes the new multi-step structure, and updates the test to navigate through all three pages correctly.
When Intent-Based Healing Works Best
Intent-based healing is most valuable in fast-moving products where UI changes are frequent and normal. SaaS onboarding flows, settings pages, billing workflows, and dashboard navigation evolve constantly as teams improve the user experience.
It works especially well when:
- The product team iterates on layouts and interaction patterns regularly
- Component libraries get refactored, changing class names and DOM structure
- Forms and navigation are reorganized to improve usability
- Multi-step flows are simplified or expanded based on user feedback
What Happens When the Goal Itself Changes
Intent-based healing is powerful, but it is not magic. If the business logic behind a flow changes fundamentally, the original test intent may no longer be valid.
For example, if a product introduces mandatory two-factor authentication, a simple "email and password" login test is no longer sufficient. In this case, JustQA flags the test for human review instead of trying to adapt automatically — with context about what changed and why adaptation was not possible.
Intent-based healing handles the vast majority of UI changes automatically, while escalating only the cases that represent real product changes requiring human judgment.
How This Changes QA Team Workflows
When regression tests survive UI changes automatically, QA teams spend their time very differently. Instead of chasing broken selectors after every release, they focus on:
- Reviewing edge cases and business logic changes flagged by Qitty
- Expanding coverage into new product areas
- Prioritizing high-risk flows for more rigorous validation
- Exploratory testing in areas where coverage is still growing
Intent-based healing does not eliminate the need for QA judgment. It eliminates the repetitive maintenance overhead that prevents QA teams from using their judgment effectively.
See Intent-Based Healing in Your Own App
The best way to understand intent-based healing is to see it work on your own product. JustQA's playground lets you paste a URL and generate regression coverage in minutes. Then, when your UI changes, you will see firsthand how the tests adapt automatically.
No credit card required. No installation. Just paste your URL and watch Qitty build regression coverage that updates itself as your product evolves.
Try JustQA free at justqa.pro