UAT result statuses
The five values you can set on a UAT cycle cell, in detail.
The five statuses
Each scenario × cycle cell takes one of these values:
| Status | When to use |
|---|---|
| Untested | The default. Nothing has been recorded yet. |
| Pass | The system behaved as the Expected result described. |
| Fail | The result didn't match. An issue is normally logged at the same time. |
| Blocked | The test couldn't be run — prerequisite missing, dependent test failed, environment unavailable. |
| N/A | The scenario doesn't apply to your business. |
Untested
This is what a freshly-seeded cycle looks like — every cell starts at Untested and stays there until someone records a real result. You can also set a cell back to Untested if you want to re-do it from scratch (for example, if you misread the steps and now want to start over).
A cycle is not ready for sign-off while any cell is still Untested.
Pass
The scenario was executed in full, every step matched, and the actual result matched what the Expected result column described. The tester is confident the system behaves correctly for this scenario.
If part of the result was right and part was wrong, the status is Fail, not Pass. Log the partial-failure detail in the issue.
Fail
The scenario didn't behave as the Expected result described. The tracker treats this as the signal that an issue exists, and offers to log one at the same step — the issue form opens pre-filled, the test is linked to it automatically, and the cell stays marked as Fail regardless of whether you complete the issue creation or cancel it.
It's normal for a first-cycle UAT to produce several Fail results. The point of cycle 1 is to find them; the point of cycle 2 (after fixes) is to confirm they're fixed.
When a Fail issue is resolved, the corresponding scenario gets re-run in a later cycle. The earlier cycle's Fail result stays — the audit trail is meant to show what happened, not be cleaned up.
Blocked
The tester couldn't execute the scenario. Some valid reasons:
- A prerequisite hasn't been set up yet (for example, the test requires a vendor record that doesn't exist).
- An earlier scenario failed in a way that prevents the dependent scenario from being run.
- An environment issue stopped the test halfway through.
Use Blocked rather than Fail when the system didn't get a chance to misbehave. A Blocked cell isn't a sign of a defect — it's a sign that something needs to clear before the test can run.
Like Fail, Blocked cells should normally have an accompanying issue describing the blocker. If the blocker is just "this is dependent on test #X which failed", reference the related issue in the description.
N/A
The scenario doesn't apply to your business. For example, a scenario testing tax retention is N/A if your account isn't using tax retention. A scenario testing a feature you've deliberately opted out of is also N/A.
Confirm N/A with your FullClarity consultant
A scenario marked N/A is not re-tested in later cycles, and its absence from the test set means there's no verification record for that area. Before marking N/A, confirm with FullClarity that the area genuinely doesn't apply — sometimes a scenario is more relevant than it first looks (for example, a "general ledger close" scenario may seem out of scope but be important for any subsidiary running on FullClarity).
What a healthy cycle looks like by the end
Different engagements aim for different bars. Common targets:
- Cycle 1: every cell has a result. Some Pass, some Fail (these become issues), occasionally Blocked or N/A. The cycle gets signed off once every cell has a final result and the Fail / Blocked outcomes have a corresponding issue.
- Cycle 2 (after fixes): every previously-failing scenario should now be Pass. Pass counts should be substantially higher than cycle 1. Remaining Fail / Blocked cells indicate work that didn't make this round.
- Cycle 3+ (rarely needed): isolated retest of any scenarios that didn't make it in cycle 2.
The pattern across cycles tells you whether the implementation is converging. If cycle 2 has more failures than cycle 1, something is wrong with the fix process and the conversation with FullClarity needs to shift.
What stays visible across cycles
A signed-off cycle's column is read-only and stays visible permanently. So a scenario that failed in cycle 1 and passed in cycle 2 shows Fail in the Cycle 1 column and Pass in the Cycle 2 column — both at the same time. This is the audit trail.
You cannot delete a cycle once it's been signed off, and you cannot delete results from a signed-off cycle. If a cycle was signed off in error, ask FullClarity — they can re-open it on their side, but it's not a routine operation.
Related
- Run a UAT cycle — the testing workflow end-to-end.
- Log an issue — including the auto-logged issue from a Fail result.
- Issue fields — what the linked-to issue captures.