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. 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.
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

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.