# Record test outcomes

Canonical: https://fairleadhq.com/docs/recorder/test-outcomes/

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Choose Recorder's supported Test case or Verify fix result after assessing the evidence, and record other scoped outcomes in Description or the external system.

## Prerequisites

- Defined expectations and observations from a test

## Inputs

- Executed checks and evidence references

## Outputs

- A scoped result summary

## Limitations

- Outcomes are tester-assessed; skipped checks and missing evidence must remain explicit

## Permissions

- Access to your test notes or result system

## Privacy

- Review content and destination before sharing


Record the result against the behavior you actually checked.

Record your assessment alongside the evidence. Recorder never assigns a result automatically. After Stop, **Test case** offers Passed, Failed, or Blocked; **Verify fix** offers Fixed or Not fixed; **Explore** has no result control.

## Compare expected and actual behavior

Start with the case's acceptance criteria or the exploratory charter. Identify which checks were executed on which build and environment. Describe the observation before deciding the result.

| Outcome | Use when |
| --- | --- |
| Passed | The defined expected results were checked and met |
| Failed | Observed behavior did not meet a defined expectation |
| Blocked | A prerequisite prevented execution |
| Incomplete | An interruption stopped the attempt before a final result; state the last completed step |
| Inconclusive | Execution or evidence did not support a reliable decision |

Use your team's equivalent statuses where needed. Keep skipped checks separate from passed ones.

## Write a result summary

Write the check, conditions, expected and actual result, outcome, and evidence references in **Description** or your TMS. Identify missing context explicitly instead of guessing it. For the [real sample](https://fairleadhq.com/docs/recorder/schema/#sample-reproduction-bundle):

```text
Check: Clear the Blocked badge when a card leaves Blocked
Application / data: Quackban, Pond Redesign, QB-DEMO sticky Blocked
Execution: 2026-10-07, 04:43:24.309 UTC; 42 seconds
Expected: In progress card has no Blocked badge
Actual: Status changes to in_progress; cropped image still shows the badge
Outcome: Failed against the tester's stated expectation
Evidence: session.md action 20; network.har entries 4–5; screenshots/003-area.png
Unknown: Application build and TMS run reference were not supplied
Scope: This capture checks In progress; Done/reload remarks concern earlier runs
```

These assessment details belong in Description even when you also choose a Recorder result. The selector stores the supported result; it does not explain criteria, gaps, or unexecuted checks. Downloaded `session.md` carries Description and `notes.md` carries saved annotations when present.

For an exploratory check, use scoped wording such as “No issue observed while testing empty and single-item baskets on this build.” For a reproduction attempt, “not reproduced” describes that attempt and does not prove a fix.

## Link the evidence

Reference the relevant [downloaded files](https://fairleadhq.com/docs/recorder/bundle-contents/) and the action or request that supports the result. For long cases, identify checkpoint order and any unrecorded intervals. A bounded [retained timeline](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention) cannot prove every step of a longer execution.

Blocked and Inconclusive remain useful written outcomes outside the selector where the chosen mode does not offer them. Never choose Not fixed merely to send an inconclusive verification. See [session and notes exports](https://fairleadhq.com/docs/recorder/bundle-contents/#session-summary-and-notes), and record the result in your TMS separately.