Skip to content

Record test outcomes

Record the result against the behavior you actually checked.

Last reviewed Open Markdown

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.

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

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.