What is a timeboxed test session in session-based test management?
answer
- One mission per block
- The clock is protected, not elastic
- Roughly an hour to two hours
- Ends in a sheet and a debrief
- The countable unit replacing the test case
basics
~20 sA session is one uninterrupted block of testing, commonly 60, 90 or 120 minutes, spent on a single charter and written up as one reviewable record. The session, not the test case, is the unit of work you plan and count.
solid answer
~50 sSession-based test management makes unscripted testing accountable by packaging it into sessions. A session has three constraints. **One charter**: a single stated mission for the whole block, so the tester is not drifting across the product. **One uninterrupted timebox**: commonly a short (about 60 minutes), normal (about 90) or long (about 120) session, with meetings, support pings and other work kept outside it. **One record**: a session sheet plus a debrief, so somebody other than the tester can see what was covered and how far it got. Because every session is roughly the same size and shape, sessions become countable — you can plan "eight sessions against the checkout areas this week" and report against it, even though no test-case list exists. If a block is interrupted badly enough that the tester loses the thread, the honest move is to end it short or abandon it, not to pretend the clock kept running.
code
pseudocode · 13 linesSESSION
charter = "Explore gift-card redemption at checkout to discover expiry-handling defects"
timebox = 90 minutes, uninterrupted
tester = one named person (or a pair)
produces = session sheet + debrief
DURING
work on-charter
note anything off-charter as an opportunity, do not chase it far
END
if interrupted badly: close the session short and record why
never extend the clock to "finish"go deeper
Be ready to define a session in one sentence — one charter, one uninterrupted block, one written record — and to name a realistic length. Interviewers mostly want to hear that it is not the same thing as unplanned poking at the product.
Explain the mechanics: what counts as an interruption, why the block is closed short rather than extended, and the on-charter versus on-opportunity split. Be able to say why roughly uniform sessions are what makes planning and reporting possible at all.
Expect to be asked how you protect sessions inside a team that treats testers as an interrupt-driven support desk, and how you spot sessions that have quietly degraded into unrecorded testing with a timer on it.
Own the question of whether the unit is right for your organisation at all — session length, how many teams share the convention, and what you lose in comparability when each team invents its own definition of a session.
### The problem sessions solve Unscripted testing is often the most productive testing a team does and the hardest to manage. A scripted approach has a natural unit of work — the test case — that can be planned, assigned, counted and reported. Exploration has none of that by default, so it tends to be described in the vaguest possible terms: "I looked at checkout for a while." A lead cannot schedule that, cannot tell whether it is enough, and cannot tell what was skipped. Session-based test management, introduced in the testing literature around 2000, fixes this by inventing a unit: the **session**. ### The three constraints **One charter.** A session is aimed at exactly one mission, agreed before it starts. Anything that keeps the tester pointed at a stated goal for the whole block counts; anything that lets them wander freely across the product does not. Work that is genuinely inside the mission is *on-charter*; a promising detour is *on-opportunity*, and the session sheet records roughly how the block split between the two. A block that came out 30% on-charter is not a failure — it is a signal that either the mission was wrong or something more interesting was found. **One uninterrupted timebox.** The literature describes short (about 60 minutes), normal (about 90) and long (about 120) sessions. The exact number matters less than two properties: the block is long enough to build a mental model of the area, and short enough that a person can hold focus and that a report is never far away. Uninterrupted is the load-bearing word. A stand-up, a support escalation or a code review dropped into the middle destroys the state the tester was carrying in their head, which is exactly the asset a session is buying. A team practising this seriously treats a session the way it treats a meeting: it is on the calendar, and interrupting it costs something. **One record.** The block produces a session sheet — the charter, the areas touched, the running notes, whatever was found, and a rough breakdown of where the time went — and then a short debrief with someone else. Without the record, the session is just testing; with it, the session is a reportable, reviewable unit. ### Why the unit matters Once sessions are roughly uniform, ordinary planning arithmetic starts working again. A tester has some realistic number of sessions per day, typically three or four rather than eight, because debriefs, setup, meetings and reporting consume the rest. Coverage can be stated as "these areas have had sessions, those have not," which is honest in a way that a case-count never is. Estimates become "we think this area needs six to eight sessions," which is falsifiable after two of them. ### A worked example An online bookstore is putting a rebuilt checkout into a release. The lead schedules eight sessions across the checkout areas: gift-card redemption, address validation, split shipments, currency and locale, and the confirmation email. One 90-minute session is chartered at gift-card redemption. Thirty-seven minutes in, the tester notices that cards redeemed shortly before a whole hour are sometimes rejected as expired; a node in the redemption path is running about eleven minutes ahead of the rest, so the expiry comparison fires early. That finding is on-charter and goes in the sheet. Later in the same block the tester notices the confirmation page taking far longer than the stated budget of 2.4 seconds at the 92nd percentile — interesting, but not this mission, so it is noted as an opportunity and left for a session of its own. The block ends on time, the sheet is written, the debrief takes six minutes, and the lead now knows that one of eight sessions is done, one area has a defect in it, and one new area is worth chartering. ### Common misreadings The most common is treating "timeboxed" as the whole idea and dropping the charter — that is just a scheduled block of poking. The second is running sessions but never debriefing or filing the sheets, which throws away the entire management value and leaves you with unscripted testing that merely looks organised. The third is padding sessions to fill a calendar; if the mission is finished in 50 minutes of a 90-minute block, close it early and say so, rather than inventing filler that pollutes the record.
- How many sessions can one tester realistically complete in a working day?Usually three or four, not eight. A 90-minute block is followed by writing the sheet, a debrief, filing anything found, and setup for the next mission — plus the meetings and interruptions every job carries. Teams that plan six or seven sessions a day are really planning six or seven blocks of testing with no reporting attached, and the reporting is the part that makes it session-based.
- What do you do when a session is interrupted halfway through?Judge whether the thread survived. A two-minute question you answered without leaving the area is noise; record it and continue. A twenty-minute escalation is not — close the session short, write up what was actually covered, and re-charter the remainder as a new session. The one thing you must not do is let the clock keep running through the interruption, because it makes the block incomparable with every other block.
- Does a session have to be run by one person?No. Paired sessions are common and often better for an unfamiliar area, since one person drives while the other watches, questions and takes notes. The session sheet then names both testers. What must not happen is two people working separately under one shared charter and one shared sheet, because you lose the ability to say what was actually covered.
A session is to exploratory testing what a timed exam paper is to studying: same length every time, one stated subject, and a marked script at the end — which is what makes twelve of them comparable.
saying these in an interview costs you the question
- Calling any block of unplanned poking a session
- Dropping the charter and keeping only the timer
- Letting the clock run through a long interruption
- Running sessions but never writing the sheet or debriefing
- Padding a finished mission to fill the timebox
- Claiming eight full sessions per tester per day