What Is Exploratory Testing? Charters, Session Notes, and Debriefs

A workspace invitation works when a new user follows the expected path. Then the team changes how invitations are revoked. The existing happy-path test still passes, but it says little about an old link opened in another browser session or after an administrator changes the intended role. Those uncertainties need investigation, not another pass through the same steps.

Exploratory testing is an approach in which learning, test design, and execution inform one another as testing proceeds. The tester observes the product, develops a test idea, tries it, interprets the result, and uses that information to choose what to investigate next. Planning remains useful. The plan can change when evidence reveals a better question.

Charters, session notes, and debriefs make that investigation easier to direct and review. They give the work a purpose and an accountable record while leaving the tester free to respond to unexpected behavior.

How Learning Changes the Next Test

In a highly scripted check, the steps and expected results are largely specified before execution. During exploratory work, the next test may depend on something that has only just become visible. If a revoked invitation opens a join page, the tester might investigate whether the page is stale, whether the final authorization still rejects the invitation, or whether an existing login changes the outcome.

The work involves more than choosing different clicks. The tester builds a model of the invitation states, identifies transitions that could violate an access rule, and selects experiments that distinguish possible explanations. Boundary analysis, state transitions, and comparisons between roles can all guide exploratory test design. Familiar techniques remain useful even when their application is decided during the investigation.

An oracle is a basis for recognizing a possible problem, such as an approved access rule, a documented promise, or consistency with another part of the product. Oracles can be incomplete or outdated. When behavior and a requirement disagree, record the disagreement and investigate it rather than silently treating either side as infallible.

Exploration can start with detailed documentation, an unfamiliar prototype, or a mature regression suite. Missing requirements are one reason to investigate, not a prerequisite. Likewise, exploratory and scripted work can coexist within the same testing effort.

Session-Based Test Management is one way to organize exploratory work into chartered, reviewable sessions with debriefs. It is not a requirement for every exploratory investigation. A particular timebox, template, pairing arrangement, or checklist does not define the whole approach. The essential feedback loop is learning that changes test design and execution.

Write a Charter That Leaves Room to Investigate

A charter gives the tester a mission and helps others understand why the investigation deserves attention. It should constrain the problem enough to be useful without prescribing every action or predicting every discovery.

Define the Mission, Boundaries, and Resources

“Test invitations” leaves too much unresolved. “Investigate whether revoked invitations can still grant workspace access” identifies a consequential question. The tester can choose variations that expose the risk instead of working through an unrelated feature inventory.

A practical charter can record:

• The target and mission: which behavior to investigate and what the team needs to learn.
• The scope and exclusions: relevant roles, states, interfaces, and important areas deferred to other work.
• The risks and oracles: what could go wrong and the references used to judge observed behavior.
• The resources: an approved environment, synthetic data, product information, permitted tools, and people who can clarify decisions.
• The freedom to adapt: which variations the tester may pursue and when a discovery needs escalation or a separate charter.

Initial test ideas are welcome. For invitations, these might include role changes, expired links, repeated use, and different login states. They are prompts for thought, not proof that every relevant condition has been covered. A checklist can remind the tester of risks without becoming a rigid sequence that prevents following new evidence.

A Charter for Revoked Workspace Invitations

The following charter, investigation, and notes are fictional teaching examples. They do not describe tests performed against a real application or defects found in a customer project.

The mission is to explore invitation revocation and role changes using synthetic users in an approved non-production workspace, to discover whether stale invitation links can grant unintended access. The assumed approved rule is that a revoked invitation must not grant membership, regardless of whether its link still opens a page.

The starting context is candidate A, a recorded browser and operating-system configuration, and an invitation fixture whose recipient, intended role, and state can be inspected. Resources include the approved access rules and permitted membership records. Billing, email-delivery reliability, and unrelated identity-provider configurations are outside this charter.

Allow variation in revocation order, login state, and role changes within the authorized environment. A serious access concern warrants immediate escalation; a different subsystem may require another charter. A team could allocate 45 minutes to this illustration, but that duration is an example planning choice, not a standard for exploratory testing. Readiness, risk, and the investigation's depth should influence the actual budget.

Follow the Evidence Without Losing the Investigation

Suppose the fictional tester first establishes how an ordinary invitation behaves and records the starting membership state. After revocation, the old link still displays a join page. That observation changes the next question: does the final join action reject the revoked invitation, or does it create membership?

A visible join page alone cannot establish unauthorized access. The interface may be stale while a later authorization check remains correct. The tester therefore inspects membership before and after the attempted join, keeping the invitation and account context identifiable. In this fictional branch, the attempted join creates membership despite the recorded revoked state. The session now has evidence of a mismatch with the assumed rule, rather than merely an unexpected screen.

The tester then investigates alternative explanations. Was the user already a member? Did an existing login or another active invitation affect the result? Repeating the relevant path with a fresh synthetic recipient and recorded starting state helps separate those possibilities. A reproducible sequence is useful evidence, but it does not by itself establish the implementation's root cause.

Next, the tester tries a role-change variation suggested by the result. An unavailable audit view prevents checking part of the intended state history. That limitation belongs in the notes. It neither invalidates the visible membership concern automatically nor establishes that every remaining role transition is safe.

Following a promising discovery can consume the session. Record why the investigation narrowed and which original questions remain open. If another high-impact concern appears outside the charter, preserve enough context to escalate it and agree on the next action. Quietly abandoning the original mission would leave the team unable to distinguish a deliberate risk decision from an accidental gap.

Keep Session Notes That Another Tester Can Interpret

Session notes should recover the investigation's reasoning, context, and evidence. Begin with the charter, tester, session date, build, environment, relevant configuration, and protected references to the synthetic data. Record expectations alongside observations, especially when a result might be disputed.

The categories below are a practical note-taking aid, not a mandatory standard or a product's field schema. Every entry and evidence label is illustrative.

Note Type	Illustrative Entry	What It Establishes
Action	Revoked the fixture invitation, then opened its saved link with the intended recipient.	The interaction attempted and the context needed to interpret it.
Observation	The join page appeared after revocation; later membership inspection showed the recipient as a member following the join attempt.	What was seen, separated from an explanation of why it happened.
Inference	Final authorization may be accepting a stale invitation state.	A hypothesis to investigate, not a confirmed root cause.
Question	Does an existing login change which invitation or role the join action uses?	An unresolved uncertainty that can guide another experiment.
Blocker	The audit view was unavailable for the role-change variation.	A limit on the investigation, not a passing result.
Defect	Revoked invitation granted membership in the reproduced path, contrary to the assumed approved access rule.	A reportable product concern with its oracle and reproducible context.
Evidence	Example labels INV-before, INV-revoked, and MEMBER-after identify the retained state captures.	How a reviewer would locate supporting material; these labels are not real attachments.

Keep the chronology clear enough to distinguish the first observation from a later controlled repeat. For a defect report, retain the relevant preconditions, inputs, expected behavior, actual behavior, and evidence references. Put uncertain explanations in a separate hypothesis or investigation note rather than in a title that asserts an unproven backend failure.

Avoid turning note-taking into continuous transcription. Record meaningful actions, changed conditions, surprising results, and reasons for changing direction. Screen recordings can help reconstruct interactions, but they do not automatically capture the tester's expectation or reasoning. Protect credentials, personal information, and sensitive state when collecting evidence, and use the team's access and retention rules.

A useful record also identifies what was not examined. “Invitation behavior tested” is too broad if the session investigated only revocation with one role and one browser configuration. Describe the actual sample and leave unsupported combinations visibly unresolved.

Debrief the Findings, Gaps, and Next Decisions

A debrief turns the session record into shared understanding and follow-up decisions. A peer, test lead, developer, or product stakeholder can help challenge interpretations and clarify the next priority. The conversation should examine the investigation, not merely whether the tester followed the original ideas.

Review the Interpretation and Remaining Risk

Start with the charter and explain what changed during testing. In the invitation example, the investigation moved from a broad set of state transitions toward a possible access-control failure. The reviewer needs to understand why that choice was reasonable and which risks consequently received less attention.

Useful debrief questions include:

• Which observations support the reported concern, and which statements remain inferences?
• Does the expected behavior match an agreed rule, or does the rule need clarification?
• Which states, roles, and configurations were examined, and which were excluded or never reached?
• What blocked further investigation, and who can remove the obstacle?
• Which next experiment would most usefully reduce the remaining uncertainty?

A session with no confirmed defect may still reveal a misunderstood requirement, an inaccessible environment, or a valuable new product model. Conversely, finding a defect does not establish adequate coverage. Assess the information gained and the remaining risk rather than using bug counts or completed-session counts as a substitute for judgment.

Give Follow-Up Work an Owner

For the fictional invitation session, separate the actions: report the reproduced membership concern, ask the access-rule owner about ambiguous role behavior, restore audit visibility, and propose another charter for the unexamined transitions. Give each action an owner and an agreed priority. An unresolved question should not disappear because it lacks a defect classification.

Retain the original session notes when a defect is later fixed or an interpretation changes. Add the new information so reviewers can recover what was known at the time. A corrected build needs its own confirmation evidence. Neither a debrief nor a successful fix retest automatically authorizes release or resolves the wider regression risk.

Reuse Stable Checks Without Freezing Future Exploration

The invitation investigation may produce a stable check: a revoked invitation must not grant membership from the specified starting state. Before reusing it, clarify the preconditions, expected outcome, relevant data reset, and evidence needed to determine the result. Decide whether a manual regression check or automation fits the risk and available interfaces. Preserve the discovery's context rather than copying every exploratory detour into a permanent script.

Keep that repeatable check alongside further exploration of different states and interactions. A fixed reproducer confirms a known behavior; it cannot answer every question raised by a change. The guide to planning release regression in Jira develops the separate decisions about release scope, execution context, and retained results.

For teams using Sherlock Test Management, this downstream review can connect a useful new check to maintained coverage. Its current product description separates human-approved, versioned test baselines from release-specific runs and presents AI-generated additions and edits as proposals requiring review. The Sherlock product workflow explains those controls. That is a connection to reviewing reusable coverage, not a claim that Sherlock records exploratory sessions or autonomously investigates the application.

Choose the next charter from the most consequential unresolved question. Keep its mission clear, its boundaries explicit, and its test choices open to what the evidence reveals.