Statuses are the labels that describe the outcome of a test result, exploratory session, or automated test run. Testmo ships with a set of built-in statuses that cover the most common testing workflows, and administrators can customize names, colors, aliases, scope, and project assignment to match how their teams work.
Status configuration is available under Admin > Statuses.
Default statuses
Testmo includes seven active statuses out of the box:
| Status | Color | Notes |
|---|---|---|
| Untested | Gray | Default status; assigned automatically to new test results |
| Passed | Green | Counts as a success and as completed |
| Failed | Red | Counts as a failure and as completed |
| Retest | Orange | |
| Blocked | Gray | Counts as completed |
| Skipped | Cyan | Counts as completed |
| Exception | Orange | Automation results only; counts as a failure and as completed |
In addition to these active statuses, Testmo reserves a number of inactive placeholder slots. Each placeholder appears as "Unnamed" in the status list until an administrator enables and configures it. This is how you add statuses beyond the built-in set: enable a placeholder, give it a name and color, and configure its scope and effects.
The Untested status
Untested is the default status automatically assigned to every new test result before a tester has recorded an outcome. It serves as a neutral baseline and cannot be disabled or removed from any project or scope. You can change its name, color, and aliases, but its other properties are fixed.
Editing a status
Click the edit button next to any status to open the edit dialog. The dialog has three tabs: Status, Scope, and Projects.
Status tab
The Status tab contains the status name, color, aliases, and effect settings.
- Name is the label displayed throughout Testmo wherever the status appears, including results, charts, and filters.
- Color is the base color used in charts, statistics, and result indicators. Darker, stronger colors work best for readability in charts.
- Aliases are additional names for the status, used when submitting results through the API or from automation pipelines. See Aliases below.
-
Settings controls what the status means in Testmo's metrics:
- Is enabled turns the status on or off. A disabled status is hidden from testers and cannot be assigned to new results. You cannot disable the Untested status, and you cannot disable a status if it is the only active status for a given scope.
- Is considered a success marks results with this status as successful for success rate calculations.
- Is considered a failure marks results with this status as a failure for failure rate calculations. A status cannot be both a success and a failure at the same time.
- Is considered completed marks results with this status as completed for progress and completion rate calculations.
Status effects and metrics
The combination of effect settings on your statuses shapes what Testmo reports across runs, milestones, and the reporting center.
- Success rate is calculated from all results marked as "considered a success." If your team uses a custom status such as "Verified" or "Approved" that you want treated as a positive outcome, enable Is considered a success for that status.
- Failure rate is calculated from all results marked as "considered a failure." Custom statuses like "Broken" or "Crash" that represent clear failures should have Is considered a failure enabled.
- Progress and completion rate reflect how much of a run or milestone has been acted on. Any status with Is considered completed enabled, including failure and blocked statuses, counts toward progress. Only the Untested status does not count as completed by default, since it represents work that has not yet been done.
These three flags are independent. A status such as Blocked has Is considered completed enabled but neither success nor failure, because a blocked result is done but carries no positive or negative signal about the test outcome itself.
Scope
The Scope tab controls which test types a status is available for. Each status can be independently enabled or disabled for the following:
- Run results makes the status available when testers are recording results in a manual test run.
- Sessions makes the status available for exploratory test sessions.
- Automation makes the status available for automated test results submitted via the CLI or API.
Limiting scope is useful when a status is only meaningful in one context. For example, the built-in Exception status is scoped to automation only, since it represents an unhandled error or crash in an automated test rather than a finding a human tester would record.
At least one active status must always remain enabled for each scope. Testmo will prevent you from disabling a status if doing so would leave a scope with no active statuses.
Aliases
Aliases are alternative names for a status that can be used when submitting test results through the API. This lets automation tools use their own native result names without requiring you to match Testmo's exact status names.
For example, the built-in Passed status has the aliases passed, ok, and success. A JUnit test runner that emits ok as a result value will automatically map to the Passed status because of this alias.
You enter aliases as a comma-separated list in the Status tab. Each alias must be lowercase and contain only letters, numbers, and underscores. Aliases must be unique across all statuses: the same alias cannot point to two different statuses.
When adding a custom status, define aliases that match the result values your test frameworks and CI tools emit. This avoids having to transform result values in your pipeline scripts.
Project assignment
The Projects tab controls which projects the status is available in.
Select This status applies to all projects to make the status universally available. This is the default for all built-in statuses.
Select This status applies to the following projects only to restrict the status to a specific set of projects. At least one project must be selected when using this option. If a status is restricted to certain projects, it will not appear in runs, sessions, or automation results for any project outside that selection.
Project-specific statuses are useful when different teams use different result vocabularies. For example, a QA team testing a mobile app might use a "Cannot reproduce on device" status that is not relevant to backend or API projects. Restricting that status to the relevant project keeps the result options clean for everyone else.
The Untested status always applies to all projects regardless of this setting.