QAM Hub QAM Hub
Home / Glossary / Custom status

Custom status

Last reviewed

A team-defined execution outcome added to the built-in set of passed, failed, blocked and skipped, such as Not applicable, Deferred or Known issue. Custom statuses exist because forcing a real outcome into the wrong bucket corrupts every pass-rate figure downstream. The decision that matters is how each one counts in reports: as a pass, as a fail, or as neither.

Also called: Custom execution status, Custom result status

Why teams add them

The built-in statuses cover most results. The few that do not fit get forced somewhere anyway. A case that does not apply to this platform gets marked Skipped and hides among the cases nobody reached. A failure caused by a bug already filed gets marked Failed again on every run, and the pass rate drops for a reason the team has already accounted for. Each choice is small. Together they make the report argue with the people reading it.

How many is too many

Every extra option slows execution and invites inconsistency, since two testers will pick different statuses for the same situation. A short list that closes real gaps beats a long one. Before adding a status, write one sentence saying when to use it and how it counts in the pass rate. If that sentence is hard to write, the new status overlaps an existing one.

The counting rule decides its value

If Known issue counts as a pass, the release looks healthier than it is. If it counts as a fail, the team re-triages the same bug every run. Counting it as neither and showing it separately keeps the pass rate honest and the known problem visible. Whatever a given tool does, the team should know which of the three applies before the status shows up in a release decision on a milestone.

In QAM Hub

On Standard and Advanced a project can add up to three custom statuses, each with a name and a colour, in Project Settings. They are neutral: they never count as passed or failed, and they appear in the run table, in Run Mode, in execution history and in every report. They apply to test runs, while checklist cells keep the fixed set. Deleting a custom status resets the results that used it to Untested. On Advanced, Release Readiness gates can cap the count of any status, custom ones included. The full list of built-in statuses is in execution statuses explained.

Back to the test management glossary