What belongs in the comment, attachment and actual-versus-expected fields of a recorded manual test result, and what makes that record useless a week later?

A manual result is more than an outcome word. The fields around it are what make the outcome checkable by someone who was not there, on a day when the environment has been rebuilt and the tester has moved to another cycle. Getting them right is a recording discipline, and it is almost entirely about anticipating that reader. ## Three fields, three jobs | Field | Its job | The failure mode | |---|---|---| | Expected | Anchors the comparison to what the case actually claimed | Restated from memory, so nobody can tell if the case was stale | | Actual | Records the observation verbatim, values and messages included | Paraphrased into it looked wrong or it did not work | | Comment | Carries the run context the comparison cannot hold | Left empty, or used to retell the steps that are already written down | | Attachment | Carries the bytes of a state that will not exist tomorrow | Promised for later, captured too wide, or never taken at all | The expected side is the one people undervalue. Copying it from the step, rather than typing what you thought should happen, is what lets a later reader settle the question of whether the **product** deviated or the **case** was out of date. Those two look identical in a record that has only the actual side. ## What the record has to survive Write for the reader who arrives after the moment is gone. By then: - the environment has been redeployed, so the state that produced the result no longer exists - the build under test has been superseded, possibly several times - the test account has been reset, or the data seeded over - the tester has forgotten the details and may be on another team Everything that only lived in that moment must be in the record or it is lost. In practice that means **identity** - the build, the environment, the account or data set, the time - plus the observation itself and one piece of evidence that shows it. ## What good evidence looks like 1. **Captured during the run**, not reconstructed afterwards. Evidence gathered by trying to reproduce it later is a different observation, and if it does not reproduce you have nothing. 2. **Scoped to the moment.** A capture of the specific screen, message or response beats a capture of a whole desktop that a reader must hunt through. 3. **Attached where it is local** - at the failing step when the tool records results per step, so the reader lands on it instead of scanning the whole case. 4. **Readable without the tool that produced it.** Evidence that needs a session, a live environment or a tester's local machine to interpret is evidence only for as long as those exist. 5. **Safe to store.** If the observation involves real customer data, capture what proves the deviation and redact the rest, or reference an identifier that points at the state instead of copying it in. ## The failure modes that kill a record These are all cheap to commit and expensive to discover: - **It did not work.** The single commonest defect in manual records: an outcome word with no observation behind it. A week later there is no way to tell what was seen. - **See the ticket.** The execution record becomes a pointer to a defect report, so anyone reading the cycle has to leave it, and if the ticket is closed or merged the trail ends. - **Expected written from memory**, which makes a stale case indistinguishable from a real defect. - **No build or environment identity**, so nobody can tell whether the observation still applies to anything currently deployed. - **Evidence to follow**, which almost never follows, because the environment is gone by the time anyone chases it. - **A wall of narration** retelling steps that are already written in the case, burying the one sentence that mattered. ## Proportion by outcome Not every result needs the same weight, and demanding it of every pass is how a team learns to write nothing at all: - **A pass** usually needs only identity - build and environment - because the case text already says what was checked. The exception is a pass that overturns a previous failure, or a check expensive enough that nobody will want to repeat it. - **A failure** needs all three fields: the comparison, the context, and the evidence. - **A blocked result** needs the obstacle named specifically, with enough identity for someone to check whether it still stands. One useful border: the execution record is not the defect report. The record's job is to make the run reconstructible and the observation checkable, which is a different artefact with a different lifetime - the record stays attached to this cycle even after the ticket it prompted has been closed, merged or rejected.