​

Failure classification

Failure classification keeps a test suite useful. Qodex does not treat every red run as a product bug. It first decides whether the failure is a real bug, a stale test, or an environment issue.

​

The three classes

When the evidence genuinely cannot tell which it is, Qodex says so instead of guessing.

​

What you see on a test run

Each failed or errored scenario on the test run page carries a label that says what the failure was: The scheduled-run email uses the same words. For a scheduled run that failed, the report is emailed when the run has a new functional regression or vulnerability. When every failure is a repair, an environment problem, or an issue that was already open, the run page shows No email: no new regressions. When some failures are not judged yet, it shows Email held: some failures are not yet judged, and the email goes out later if one of them turns out to be a regression.

​

Why this matters

Without classification, a renamed button, a staging outage, and a real authentication regression all look the same. That creates noisy reports and missed bugs. With classification:

• Selector drift becomes a stale-test task.
• Staging downtime becomes an environment note.
• Product regressions become findings.

​

Examples

​

Security note

For security scenarios, the classifier still runs first. If the failure is a real bug, security rules then interpret it with inverted semantics: fail means the app allowed the attack, and the run labels it Vulnerability present.

​

Related