> ## Documentation Index
> Fetch the complete documentation index at: https://qodex.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# My tests are flaky. What does Qodex do about it?

> Qodex classifies failures, repairs many UI replay issues, and requires evidence before turning failures into findings.

# My tests are flaky. What does Qodex do about it?

Qodex tries to separate product bugs from noisy test failures.

When a run fails, Qodex looks at the evidence and classifies the failure as a real bug, stale test, or environment issue. For UI scenarios, it can also recover from many selector and layout changes.

![Qodex failure analysis explaining why a test failed and recommending a fix](https://mintcdn.com/qodexai/rhkO1RmGEPTQ07wr/images/docs/findings/failure-analysis.png?fit=max\&auto=format\&n=rhkO1RmGEPTQ07wr\&q=85\&s=30652d9863dd79e98f2b9e0eace20bb1)

## Failure classification

| Classification | Label on the test run | Meaning | What to do |
| - | - | - | - |
| Real bug | **Functional regression**, **Vulnerability present**, or **Still present** | The product behavior appears broken | Use the finding evidence to fix the app. |
| Stale test | **Test needs repair** | The scenario no longer matches the product | Update or regenerate the scenario. |
| Environment issue | **Environment** | The target, network, data, or auth setup failed | Fix the environment and rerun. |

A failure labeled **Not yet judged** has not been classified yet. Treat it as unknown, not as clean.

This keeps temporary staging problems and stale selectors from automatically becoming product findings. Scheduled runs whose only failures are repairs, environment problems, or already-open issues do not send a failure email.

## UI replay recovery

UI scenarios replay cached browser actions.

If a selector changes but the step intent still makes sense, Qodex can resolve the intent against the current page and continue. A small label, layout, or selector change does not always require a manual test update.

## Evidence guard

Qodex expects evidence before opening high-severity findings.

That evidence may include a screenshot, DOM snapshot, request, response, console output, or replay trace. This reduces the chance that a single missed selector becomes a confident product bug.

## What you should do

* For **Test needs repair**, click **Fix in chat** on the failed result, update the scenario, and rerun it.
* For **Environment**, fix the target, data, network, or auth setup.
* For a real bug, review the evidence and fix the product behavior.
* To understand what a result actually returned before deciding, click **Ask in chat** on it.

## Roadmap

Flaky-test detection and auto-repair proposals for stale tests are planned. That will help Qodex treat frequently noisy tests differently from newly failing tests.

## Next steps

> [card] [Failure classification](https://qodex.ai/docs/findings-failure-classification.md)
>
> Learn the three failure types.

> [card] [Replay cache and self-healing](https://qodex.ai/docs/ui-testing-replay-cache.md)
>
> See how UI recovery works.

> [card] [Findings](https://qodex.ai/docs/concepts-findings.md)
>
> Understand what becomes a finding.

> [card] [Re-run failed tests](https://qodex.ai/docs/run-tests-rerun-failed.md)
>
> Rerun only failed scenarios.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.