skip to content

What does a session sheet record after an exploratory test session?

level: middleimportance: must knowfreq 51%

answer

  1. A small fixed set of fields
  2. Product problems, and testing problems, kept apart
  3. Where the time went, roughly
  4. Written for a stranger to read
  5. Charter, areas, notes, bugs, issues, split

basics

~20 s

A session sheet records the charter, the areas covered, the tester and start time, running test notes, the defects found, the obstacles hit, and a rough split of where the time went. It is the session's only durable output.

solid answer

~50 s

The sheet is a small, fixed set of fields so that dozens of sessions can be read and compared. It carries the **charter** it was run against, the **areas** touched, the **tester** and **start time**, any **data files** used or produced, free-form **test notes** describing what was actually tried, the **bugs** — things believed wrong with the product — and, separately, the **issues**: obstacles, questions and risks about the testing itself, such as a missing account, an unusable environment or a charter that turned out to be wrong. It also carries a **task breakdown**: roughly how the block split between setup, test design and execution, and investigating and writing up defects, plus the on-charter versus on-opportunity share. Keeping bugs and issues apart is the field distinction interviewers probe most, because issues are what a lead can actually act on to make the next session more productive.

code

pseudocode · 18 lines
pseudocode
CHARTER:   explore gift-card redemption at checkout
           with expiring and expired cards
           to discover expiry-handling defects
AREAS:     checkout / gift-card redemption / expiry handling
TESTER:    one named person
START:     timestamp, duration 90 min

TASK BREAKDOWN (estimated, not timed):
  setup 45%  |  design+execution 30%  |  bug investigation 25%
  on-charter 70%  |  on-opportunity 30%

DATA FILES: hand-crafted card set, 14 cards, mixed expiry offsets

TEST NOTES:
  ...what was tried, seen, ruled out...

BUGS:   short line + tracker id
ISSUES: obstacles to the testing itself, questions, risks

go deeper

for a junior

Learn the field list and be able to recite it: charter, areas, tester and time, data files, notes, bugs, issues, task breakdown. Knowing that obstacles are recorded separately from product defects already puts you ahead of most candidates.

for a middle

Explain why each field exists and what a reader does with it. The two mechanics to have ready are the bugs-versus-issues separation and why the time split is estimated at the end rather than timed during the block.

for a senior

Be able to read a stack of sheets as a diagnosis: setup dominating the breakdown, an issues column nobody clears, or notes so thin that coverage cannot be reconstructed. Say what you would change in the environment or the charters as a result.

for a principal

Own the tension between a sheet that is cheap enough to write honestly and one detailed enough to be evidence. Be ready to argue what you would cut from the template first when adoption stalls, and what you would never cut.

### Why a fixed shape A session sheet is deliberately small and deliberately uniform. Its job is not to be a beautiful report; it is to make twelve sessions from four testers legible to somebody who ran none of them. That only works if every sheet has the same fields in the same order, so a reader can skim the charter and the areas, and drop into the notes only when something looks interesting. ### The fields **Charter.** The mission the block was run against, copied verbatim. If the charter was revised mid-session, both versions belong on the sheet — a revised mission is itself a finding. **Areas covered.** The parts of the product, the platforms, the data sets or the quality attributes actually touched. This is the field that later answers "what have we looked at and what have we not," so it should use whatever area vocabulary the team already reports in, not ad-hoc phrasing invented per sheet. **Tester and start time.** Who ran it, when it began, and how long it ran. Naming the tester is not surveillance; it is how a reader knows whose head to go into when the notes are terse. **Test notes.** The bulk of the sheet, and free-form on purpose: what was tried, what was observed, what was ruled out, what the tester was thinking. Notes written for a future reader beat notes written as a private memory aid — a useful discipline is to imagine the sheet being read six weeks later by someone deciding whether to re-test this area. **Data files.** Any input file, seeded account, generated data set or capture the session depended on, so the work can be picked up again without reconstruction. **Bugs.** Things believed to be wrong with the product. The sheet holds a one-line pointer and the identifier from wherever defects are actually tracked; the full defect record and its triage life belong in the tracker, not here. **Issues.** Everything that got in the way of testing rather than being wrong with the product: a broken test environment, missing permissions, a question nobody could answer, a charter that turned out to be unscopeable, a tool that would not install. This field is the quiet value of the whole technique. Bugs tell you about the product; issues tell you why testing is slower than expected, and they are the list a lead can shorten. **Task breakdown.** A rough percentage split of the block across session setup, test design and execution, and bug investigation and reporting, plus the on-charter versus on-opportunity share. These are **estimated at the end of the session, not stopwatched.** The point is not accounting precision; it is to expose a pattern — if setup is eating 40% of every block, the environment is the problem, and no amount of extra sessions will fix it. ### A worked example A 90-minute session on an online bookstore is chartered at gift-card redemption during checkout. The sheet names the tester, records areas as *checkout / gift-card redemption / expiry handling*, and the notes describe redeeming cards at a range of expiry offsets. Under bugs: cards expiring within the current hour are rejected as already expired, because one node in the redemption path is running about eleven minutes ahead of the others. Under issues: the seeded gift-card generator could not produce cards expiring in the past, so half the intended cases needed hand-crafted data, and nobody could say which service is authoritative for time. Under task breakdown: roughly 45% setup, 30% test design and execution, 25% investigating and writing up the defect, and about 70% on-charter. That last line is the sentence a lead should react to — this area is expensive to test until the data problem is fixed, and the next session against it will be no faster. ### Failure modes The sheet becomes a form to be filled rather than a record to be read. Symptoms: notes that say "tested checkout, all good"; every issue logged as a bug so the issues field is permanently empty; a task breakdown that is 33/33/34 on every sheet because someone is generating it; and areas written in prose that no two sheets share, which makes coverage unanswerable. The correction is not a bigger template — it is a debrief where somebody actually reads the sheet and pushes back on it.

  • What is the difference between the bugs field and the issues field on a session sheet?
    Bugs are things believed to be wrong with the product; issues are things that got in the way of testing it — a broken environment, missing data, an unanswerable question, a charter that could not be scoped. They are separated because they go to different people and produce different actions. A pile of bugs is a product signal; a pile of issues is a signal that the next ten sessions will be as slow as the last ten unless someone clears them.
  • Why is the task breakdown estimated at the end rather than measured with a timer?
    Because stopwatching would cost more attention than the number is worth and would fragment the very focus the timebox is buying. The breakdown is meant to surface coarse patterns — setup swallowing half of every block, or investigation crowding out execution — and a tester's end-of-session estimate is accurate enough for that. Treating those percentages as precise accounting is the misuse: they are a smell detector, not a timesheet.
  • How much detail should the test notes carry?
    Enough that a colleague can tell what was covered and reconstruct anything surprising, and no more. Useful notes record what was tried, what was observed and what was deliberately not touched. Notes that only record successes are near-worthless, because the value of the sheet later is mostly in knowing where the tester looked without finding anything.

saying these in an interview costs you the question

  • Logging every obstacle as a product bug
  • Notes that only say the feature worked
  • Treating the time split as precise accounting
  • Duplicating the full defect record onto the sheet
  • Free-form area names that no two sheets share
  • Filling the sheet days later from memory

context

resolving links…