> For the complete documentation index, see [llms.txt](https://docs.does.qa/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.does.qa/choosing-a-test-automation-approach/maintenance-and-reliability.md).

# Maintenance and reliability

How DoesQA keeps maintenance low, stays resilient when the UI changes, and delivers reliable Run results you can trust.

DoesQA is built so people with basic automation knowledge can keep coverage healthy without owning a code framework. Shared [Elements](/elements/creating-elements.md), [Step Groups](/better-coverage/reuse-steps-with-step-groups.md), and [Flow Branches](/better-coverage/choose-flow-branch-shapes.md) sit at the centre of that model.

The headliner is reliability: when a Test Case fails, treat the result as real, stop on red, and investigate. DoesQA builds and runs the full stack so Results stay trustworthy.

## How reliable are DoesQA tests?

DoesQA is designed to be flake-free. The product, the Test Runners, and the way Test Steps wait and resolve Elements are one platform, built and managed together for reliable results.

Application code has bugs. That is why teams automate. Coded frameworks add another layer of custom code around those journeys, so bugs can land in the tests themselves. In DoesQA every customer runs the same tried and tested Test Steps. There is no room for each team to code fresh bugs into the step layer.

There is also no hand-off between your tests and a third-party remote runner. With a split stack it is common for the runner vendor to blame your tests, and for the test authors to blame the runner. Inside DoesQA the Flow, the Steps, the Runner, and the Results are one system. When something is wrong, it is DoesQA's responsibility to fix it.

That means:

* A **pass** is a pass you can ship against.
* A **fail** is a fail you should investigate, not something to rerun until it goes green.

Open the failing Test Case, read the step timeline, screenshots, and any [AI Summary](/platform/doesqa-ai.md#test-and-run-summaries), then fix the Flow, the Element, or the application. See [Understand your results](/getting-started/understand-your-results.md).

## How much test maintenance does DoesQA require?

DoesQA does not aim for zero maintenance. It aims for **fast, centralised** maintenance that stays manageable **as the suite grows**.

With durable Selectors, a light UI change often needs **no** Flow edits at all.

When Selectors or journeys do need updating, you change them in one place:

| Change this                                                                    | What updates with it                         |
| ------------------------------------------------------------------------------ | -------------------------------------------- |
| An [Element](/elements/creating-elements.md) (shared Selector)                 | Every Test Step that uses that Element       |
| A [Step Group](/better-coverage/reuse-steps-with-step-groups.md)               | Every Flow that includes the group           |
| Shared steps on a [Flow Branch](/better-coverage/choose-flow-branch-shapes.md) | Every Test Case path that shares those steps |

That is how teams bring large suites in line in minutes, including **100+ Test Cases**, instead of editing the same journey in many coded files. Over time, new Flows keep reusing the same Elements and Step Groups, so maintenance work stays on shared building blocks rather than growing linearly with every Test Case.

Anyone with **basic automation knowledge** can maintain DoesQA. You do not need a dedicated automation-engineering team to own a framework repository.

For the build model compared with code, see [Codeless vs coded test automation](/choosing-a-test-automation-approach/codeless-vs-coded.md).

## How resilient are DoesQA tests when the application changes?

Resilience comes from shared Elements and human control over Selector updates. DoesQA moves fast when a Selector must change, and a person stays involved when it does.

### Selectors stay stable until you change them

When an Element is created or updated, DoesQA stores its Selector. Later Runs use that Selector.

Silent self-healing leads to flaky tests and false positives. DoesQA keeps the human in the loop instead.

### Update a Selector with a person in the loop

If the page changes and a step starts failing, open the [Element](/elements/creating-elements.md) and choose how to fix it:

1. **Update the Selector yourself** (Manual), or
2. **Clear the Selector** and keep the Description on an Automatic Element so DoesQA can create a new Selector on the next Run.

Review what lands, then confirm with a Run. Guidance for Selectors that survive redesigns is in [Choose durable selectors](/better-coverage/choose-durable-selectors.md).

## Does DoesQA produce flaky tests?

DoesQA is built so you should not expect flaky Tests as normal behaviour. Automatic waiting, fixed Selectors, and human-approved Selector updates are there so red means something real. Every finished Test Case keeps a step timeline, screenshots, and video on the Run, so you can prove what happened instead of guessing.

When a Test Case fails, stop on red and investigate. Use the step response, screenshots, and video on the Run. If the application is fine, update the Element or Flow with the shared tools above, then confirm with a new Run.

## Waiting, timing, and control

Most Test Steps **wait automatically** for the Element or state they need. You do not have to sprinkle sleeps through a healthy Flow.

You still stay in control when you want to:

* Tighten or limit automatic waiting on a step.
* Add manual [Wait](/test-steps/runner/wait-for-element-to-be-displayed.md) or [Pause](/test-steps/runner/pause.md) steps.
* Add **time-based Checks** (for example [Check load time](/test-steps/check/check-load-time.md)) so a silent slowdown fails the Test Case on purpose.

## Maintenance compared with coded tools

Coded frameworks such as Playwright put maintenance in repositories: page objects, helpers, reviews, and pipeline ownership.

DoesQA puts maintenance in the product. Testers update Elements, Step Groups, and Flows directly. Shared building blocks and one platform mean DoesQA is **at least 400% faster** to maintain than coded frameworks for the same journeys.

The surrounding runners and results are already there. For a fuller comparison and the [hidden costs of free](/choosing-a-test-automation-approach/doesqa-compared.md#hidden-costs-of-free) frameworks, see [DoesQA, Playwright, Cypress, and Selenium compared](/choosing-a-test-automation-approach/doesqa-compared.md).

## Related

* [Codeless vs coded test automation](/choosing-a-test-automation-approach/codeless-vs-coded.md)
* [DoesQA, Playwright, Cypress, and Selenium compared](/choosing-a-test-automation-approach/doesqa-compared.md)
* [Security and trust](/choosing-a-test-automation-approach/security-and-trust.md)
* [Coverage and speed](/choosing-a-test-automation-approach/coverage-and-speed.md)
* [Choose durable selectors](/better-coverage/choose-durable-selectors.md)
* [Creating Elements](/elements/creating-elements.md)
* [Reuse steps with Step Groups](/better-coverage/reuse-steps-with-step-groups.md)
* [Choose Flow Branch shapes](/better-coverage/choose-flow-branch-shapes.md)
* [Understand your results](/getting-started/understand-your-results.md)
* [DoesQA AI](/platform/doesqa-ai.md)