# Execute a test case

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

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

Agent summary: Use Test case, map expected results to evidence, choose Passed, Failed, or Blocked, and complete the manual TMS handoff.

## Prerequisites

- Recorder installed; an authoritative test case, environment, and safe data

## Inputs

- Test-case ID, expected results, run reference, and attempt conditions

## Outputs

- A Passed, Failed, or Blocked recording with checked evidence

## Limitations

- TMS search and result synchronization are unavailable; early steps can leave the retained interval

## Permissions

- Authorization to test the application and update the external test run

## Privacy

- Review captured and authored evidence before downloading or sending


Run one identifiable manual test attempt, choose a supported result, and attach evidence another person can verify.

Use this workflow for one planned manual case or one named checkpoint of a longer case. Select **Test case** so Recorder stores the case reference and offers **Passed**, **Failed**, or **Blocked** after Stop. Recorder does not fetch the case or update its run in a test-management system (TMS).

> **Example references:** lane and badge examples use the [Quackban sample](https://fairleadhq.com/docs/recorder/testing-workflows/#shared-example-quackban). Apply the decisions to your own case criteria.

## Follow this 10-step path

1. Select **Test case** and enter the authoritative case ID, such as `TC-142`.
2. Add a recognizable Title and write the run, build, role, safe data, covered steps, and expected results in **Description**.
3. Select **Start recording** and execute the case at its intended pace.
4. Capture every decisive visible result with its subject and surrounding context.
5. Select **Stop → Investigate** before the relevant checkpoint leaves the [retained timeline](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention).
6. For each criterion, confirm the intended action, relevant data, and visible state; retain positive evidence for a pass as well as discrepancies for a failure.
7. Add source comments naming the case step, expected result, observation, and evidence limit.
8. Choose **Passed**, **Failed**, or **Blocked** only after every required criterion's status is known.
9. Finish Description and use **Add → Notes** to insert the reviewed evidence.
10. Review privacy, download or send, enter the result in the TMS manually, verify the attachment, then use **New recording**.

## Know who supplies each part

| Part | Recorder | Tester | Destination |
| --- | --- | --- | --- |
| Test-case ID | Stores the typed value; does not search a TMS | Enter the exact authoritative ID | Report metadata and Description context |
| Case content | Does not import steps or expectations | Keep the source case open and name covered steps | Remains authoritative in the TMS |
| Browser evidence | Captures supported actions, requests, logs, timing, and images | Decide which sources establish each criterion | Viewer, report, and local files |
| Result | Offers Passed, Failed, Blocked after Stop | Choose from checked criteria, not error counts | Report and supported send text |
| Issue | Offers create/no-issue for Failed or Blocked when a tracker is configured | Decide whether the result warrants a defect | Issue tracker; independent of the TMS result |
| TMS result | Shows the destination as unavailable | Enter result, step, and attachments manually | External TMS |

The Test case field is presented as required, but Start does not enforce it. If you omit it, the report cannot identify the authoritative case. Correct the field before handoff rather than relying on the Title.

## Prepare an identifiable attempt

For a short case, use one recording per attempt. For a longer case, choose checkpoints that fit the retained interval, such as `C1 — create card` and `C2 — move card`. Keep their order and uncovered gaps in the external run.

Use a Title such as `TC-142 - A1 - pending - Move card`. In Description, record the run and attempt, covered steps and expected results, application build and role, safe data reference, pre-Start setup, and conditions Recorder cannot infer from Environment.

## Match each criterion to evidence

Treat every expected result as a small chain: **intended action → affected subject → returned or visible state**.

1. In **Actions → Recorded Actions**, open the relevant step and inspect **Target**, captured value, form state, page changes, and URL changes.
2. Open its request count when the criterion depends on data. Check Payload and Response or the next read for the same subject.
3. Open the checkpoint image. Verify enough context to judge the criterion.
4. Use Timeline and request Timing when the image might precede completion or a later update might change the result.
5. For keyboard checks, turn **Key actions only** off. For missing traffic, search Network directly.

Pin supporting evidence, then add a Notes comment using `Step → expected → observed → limit`.

## Choose the result

| Result | Use it when | Include |
| --- | --- | --- |
| **Passed** | Every required criterion was checked and met | Positive evidence for decisive checks |
| **Failed** | An executed criterion did not meet its expectation | First failed step, expected/actual, and unexecuted steps |
| **Blocked** | A missing prerequisite prevented the required check | Blocker, last reached step, and what remains untested |

Do not choose Passed because Overview is clean, requests return 200, or the action sequence completed. If evidence is inconclusive, say so in Description and repeat or hand off manually; Recorder has no Inconclusive result choice.

## Write, deliver, or recover

```markdown
Test case: TC-142 — Move card between lanes
Run / attempt / checkpoint: release-42 / A1 / C1
Build / environment / role: [fill in]
Data: [safe reference]
Result: Failed
Expected: [criterion]
Observed: [specific result]
Remaining steps: [not executed / completed]
Evidence: [NOTES]
Bug: [issue ID or triage pending]
```

Insert Notes, review Preview, and resolve any Description save error. Open Privacy preview, select **Download report**, and inspect the actual files.

Enter the result and failed/blocked step in the TMS manually. Failed or Blocked can create an issue or keep **No issue**; Passed has no issue action. **Send data to Fairlead** stores the report only. The locked TMS item does not mean anything was synchronized.

If evidence or a download is incomplete, retain the ready session and retry. Preserve a failed long-case recording before making a focused reproduction. Use A2 for a rerun, and select **New recording** only after the external run points to evidence that opens.

[Choose another testing workflow](https://fairleadhq.com/docs/recorder/testing-workflows/).