Exploratory Testing Charter

Design and execute a session-based exploratory testing charter for a user registration feature — practising mission-focused charter writing, structured session notes, risk-based coverage, and SBTM debrief technique.

Role

Manual QA engineer

Difficulty

Intermediate

Time limit

60–90 min

Scenario

Your team is releasing a new user registration feature next week. Automated regression tests cover the documented happy path, but the team wants unscripted exploratory coverage before the release goes live. You have a 60-minute time-boxed testing session. Using session-based test management (SBTM), design a focused exploratory charter for the registration flow, execute the session (or simulate it against a comparable publicly accessible registration page), record structured session notes throughout, document all bugs and anomalies found, capture questions raised, and produce a full session debrief — including a follow-up charter for any areas you did not reach.

Requirements

1.Write an exploratory testing charter in SBTM format with four sections: Mission (a single focused statement of what you are investigating and why), Areas under test (specific parts of the feature in scope), Risks to investigate (the highest-risk behaviours or edge cases you are targeting), and Time-box (the duration)
2.Execute or simulate at least 60 minutes of exploration and record running session notes during the session — not reconstructed from memory afterward
3.Document all bugs, anomalies, and suspect behaviours found during the session; each entry must have enough detail to file as a standalone bug report
4.Record all questions raised during the session that require clarification or a follow-up investigation (separate list from bugs)
5.Produce a session debrief including: areas covered vs. planned, areas not reached, approximate SBTM time breakdown (% Setup / % Testing / % Bug Investigation), and overall session judgement (productive, constrained, or inconclusive)
6.Propose at least two follow-up charters derived directly from what you discovered or did not cover — each must have its own specific mission statement
7.Classify the severity of each bug found (Critical / High / Medium / Low) and note which would block release

Starter data

›Registration feature context: email + password signup; optional first/last name fields; mandatory email verification before account is activated; optional social signup via Google or GitHub
›Known constraints: password must be at least 8 characters; email uniqueness enforced; social-auth users share the same account namespace as email/password users
›Suggested practice target: any publicly accessible SaaS product with a registration flow, or a personal staging environment — do not use a production system you do not own
›SBTM reference — Charter: Mission + Areas + Risks + Time-box | Session: Notes + Bugs Found + Questions Raised | Debrief: Coverage + Time Breakdown + Follow-ups
›Time breakdown guideline: Setup (opening the app, reading context) should be < 10% of session time; Bug Investigation (reproducing/documenting a find) ideally < 25%; Testing (active exploration) should be ≥ 65%

Expected deliverables

✓A completed exploratory testing charter with Mission, Areas, Risks, and Time-box
✓Raw session notes from the full exploration period — can be bullet-pointed and stream-of-consciousness, but must be sequenced (timestamps or approximate elapsed time)
✓A bugs-and-anomalies log with at least three entries, each with: description, steps to reproduce, actual vs. expected result, and severity
✓A questions-raised list with at least three items (clearly separated from the bugs log)
✓A session debrief: coverage summary, SBTM time breakdown (%), and overall session judgement
✓At least two follow-up charter proposals, each with a specific mission statement

Evaluation rubric

Dimension	What reviewers look for
Charter focus and mission clarity	Is the mission specific enough to guide 60 minutes of purposeful exploration? A mission of 'Test the registration feature' fails — it provides no direction. A mission of 'Investigate the registration flow's resilience to invalid and duplicate inputs, focusing on error messages, duplicate-email handling, and password strength enforcement' passes. The mission should answer: what am I investigating, in what area, and with what risk hypothesis?
Coverage of risk areas	Does the charter identify the highest-risk areas of the registration flow? These include: email validation edge cases (plus-addressing, very long emails, international characters), duplicate account handling, password strength enforcement (or lack thereof), email verification expiry, social-auth failure paths, and race conditions on concurrent registration attempts. A charter that lists only 'registration form fields' has not done risk analysis.
Quality of session notes	Are notes sequenced with elapsed time or timestamps? Do they capture both what was tested and what was observed — not just a list of actions? Good notes read like a navigator's log: '09:05 — tested email with leading space; accepted without trimming — question raised about normalisation'. Weak notes read like a checklist: '✓ tested email field'. The former lets a colleague reconstruct the session; the latter does not.
Findings value	Are the logged bugs and anomalies specific enough to act on? Do they include the exact input that triggered the behaviour, the observed output, and the expected output? Do they go beyond surface-level observations (e.g. 'form accepted plus-addressing (user+tag@example.com) as a unique email — it is unclear whether this is intended behaviour or a duplicate-detection gap')? A session that reports zero findings is not automatically a failure — a well-justified 'no bugs found, here is the evidence' is a valid outcome.
Follow-up thinking and debrief quality	Do the follow-up charters show that the tester is thinking about what they did NOT cover, not just what they found? Are they scoped — not 'test everything else'? Does the debrief's time breakdown reveal anything useful about the session's structure (e.g. if Bug Investigation was > 40% of time, was the tester spending too long on a single find instead of covering breadth)?

Sample solution outline

›Charter: Mission — 'Investigate the registration flow's resilience to invalid inputs, duplicate accounts, and social-auth edge cases, with focus on email validation, password enforcement, and error message quality'; Areas — email field, password field, name fields, social auth (Google/GitHub) buttons, email verification flow; Risks — duplicate email silently accepted, weak password (e.g. 'password123') allowed, social auth and email/password accounts merge incorrectly, verification link does not expire; Time-box: 60 minutes
›Session notes (sample, ~10 min): 00:00 — opened registration page; noted two social auth buttons (Google, GitHub). 00:03 — registered with valid new email; success, verification email received in ~20 sec. 00:07 — attempted duplicate registration with same email; error shown 'Email already in use' — correct. 00:10 — tried email with plus-addressing (user+tag@example.com); accepted as new account — question: is this intended?
›Bug-1: Password field accepts 'password123' with no strength warning or rejection — if no minimum complexity policy exists, document as observation; if policy exists, file as Severity: High. Bug-2: Registration form does not trim trailing whitespace from email field — 'user@example.com ' (with space) registers as a new account separate from 'user@example.com'. Bug-3 (if applicable): Clicking 'Sign up with Google' after already registering with the same email via email/password shows a generic error with no guidance on what to do next.
›Questions raised: (1) Is plus-addressing in email intended to create unique accounts or be normalised to the base address? (2) Does the password field enforce any complexity rules beyond minimum length? (3) What is the verification email link expiry period and is there a resend mechanism?
›Debrief: Areas covered — email validation, duplicate detection, password rules, social auth happy path, duplicate-account error; Areas NOT covered — verification email expiry, resend verification, mobile viewport, concurrent registration race condition; Time breakdown — Setup 5%, Testing 68%, Bug Investigation 27%; Follow-up charter 1: 'Investigate email verification link behaviour: expiry period, resend functionality, and behaviour when the same link is clicked twice'; Follow-up charter 2: 'Test registration on mobile viewports (iOS Safari 390px, Android Chrome 360px) focusing on form usability and keyboard behaviour'

Common mistakes

Writing a charter that is indistinguishable from a scripted test plan — exploratory charters define a mission and target risks, not a list of steps to follow; if the charter fully prescribes what to do, the tester loses the freedom to follow interesting threads
Reconstructing session notes from memory after the session — notes written during exploration capture decisions made in real time (why you went down a certain path, what caught your eye); post-hoc reconstruction loses this signal
Spending the entire session on the happy path — the value of exploratory testing is in areas automated tests are less likely to cover: error paths, edge cases, unusual input sequences, and unexpected feature interactions
Confusing bugs with questions — 'Does it accept plus-addressing?' is a question; 'Form accepts plus-addressing and creates a duplicate account, bypassing uniqueness enforcement' is a bug; record them in separate lists
Writing vague follow-up charters such as 'test more edge cases' — follow-up charters should be as mission-focused as the original: they answer what, where, and with what risk hypothesis
Not recording the SBTM time breakdown — the setup/testing/bug-investigation split is a diagnostic: if Bug Investigation consumed 50% of the session, the tester got stuck on one find instead of covering the planned areas; this is a learning signal, not a failure

Submission checklist

Completed charter with Mission, Areas, Risks, and Time-box
Charter mission is specific — names what is being investigated and the risk hypothesis, not just 'test the feature'
Session notes cover the full exploration period with sequencing (timestamps or elapsed time)
At least three bugs/anomalies documented with description, steps, actual vs. expected, and severity
Questions-raised list with at least three items, clearly separated from the bugs log
Session debrief includes: areas covered, areas not reached, SBTM time breakdown (%), and overall session judgement
At least two follow-up charters proposed, each with a specific mission statement
At least one bug is classified as to whether it would block the upcoming release

Extension ideas

+Execute one of your follow-up charter sessions and compare its findings with the first session — did the second session uncover higher- or lower-severity issues?
+Compare your exploratory findings against a scripted test case set for the same feature — identify which issues only exploratory testing caught and analyse why
+Practise the SBTM debrief with a colleague: present your session report in 10 minutes, have them ask follow-up questions, and note which parts of your report were ambiguous under questioning