Record test outcomes
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
Section titled “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
Section titled “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:
Check: Clear the Blocked badge when a card leaves BlockedApplication / data: Quackban, Pond Redesign, QB-DEMO sticky BlockedExecution: 2026-10-07, 04:43:24.309 UTC; 42 secondsExpected: In progress card has no Blocked badgeActual: Status changes to in_progress; cropped image still shows the badgeOutcome: Failed against the tester's stated expectationEvidence: session.md action 20; network.har entries 4–5; screenshots/003-area.pngUnknown: Application build and TMS run reference were not suppliedScope: This capture checks In progress; Done/reload remarks concern earlier runsThese 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
Section titled “Link the evidence”Reference the relevant downloaded files and the action or request that supports the result. For long cases, identify checkpoint order and any unrecorded intervals. A bounded retained timeline 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, and record the result in your TMS separately.