I understand exploratory testing as purposeful investigation in which the next question changes in response to what we learn. It is neither a fixed script nor aimless clicking. A session needs a goal, a time boundary and a record. A charter briefly defines the area to explore, the risk to investigate and the evidence sought. It is particularly useful where requirements are ambiguous, dependencies are complex or unusual combinations of user actions may matter.
A standard banking-app scenario might confirm that an authenticated customer can submit a payment. Exploration can investigate interruption, repetition, returning to an earlier screen or changing permissions during an unfinished operation. Not every surprise is a defect. The tester must distinguish a need to clarify a rule from incorrect behaviour and from a newly discovered risk that nobody has yet defined precisely enough to make a reliable judgement.
A real case: TSB, United Kingdom, April 2018
TSB experienced extensive banking-service disruption after its April 2018 platform migration. In December 2022 the FCA and PRA announced combined penalties of GBP 48.65 million for operational-risk and programme-governance failings. Their announcement states that the data migrated successfully, while the new platform immediately experienced technical failures.
This does not prove that a particular exploratory session would have prevented the incident, nor does the announcement disclose every test performed. My analytical lesson is to distinguish successful data transfer from a functioning service. I would investigate complete customer outcomes and dependencies rather than accept one technical milestone as evidence of readiness. This is a lesson from a UK case, not an assertion that identical legal duties apply elsewhere.
Write a charter that guides decisions
“Test payments” is too broad. A more useful charter would investigate connection loss after confirming an outgoing payment, with the aim of determining whether the customer can establish its actual state and whether retrying creates a duplicate. This does not prescribe every action. It gives the tester a frame for choosing combinations, interpreting responses and recording the situations that remain unexplored when the session ends.
Before starting I would establish the environment, permissions, test accounts and safe transaction limits. Transfers should be simulated in an authorised test environment rather than improvised in production. I would record simulator limitations and available evidence: request identifiers, event timestamps, status history and the message shown to the customer. Missing evidence limits the conclusion. A confirmation screen alone does not prove the operation completed correctly throughout the processing chain.
An illustrative session: an uncertain payment outcome
Imagine a ninety-minute session using a fictitious CZK 1,000 transfer between test accounts. Fifteen minutes establish the normal flow and prepare evidence capture. Forty minutes vary the point of connection loss: before submission, after server acceptance and before the response is displayed. The remaining time supports reproduction and a joint review of the most important observation. These times and figures are illustrative, not a reconstruction of a bank incident.
If the customer receives an error while the balance changes, the next question is what they can safely do. I would refresh transaction history and perform a controlled retry, checking whether the same operation is recognised and whether processing status agrees with the displayed status. Slowness alone is not the central finding. A discrepancy matters when it encourages an incorrect next action, such as resubmitting an already completed payment without understanding the consequence.
A second branch could change authorisation. Suppose a staff member may prepare a payment but cannot approve it. I would examine a form left open while their role changes and ask where permission is checked at the decisive moment. Hiding a button is not sufficient evidence of correct server-side authorisation. I would agree the verification method with technical specialists so that investigation stays within the authorised scope and produces interpretable evidence.
Record observations without prematurely deciding the cause
I would maintain a short timeline of purpose, variation, observation and the next question. “Two entries with the same amount appeared after retrying” is an observation. “The server has no duplicate protection” is a hypothesis requiring transaction identifiers and actual booking evidence. Keeping these separate helps a developer continue the investigation without first having to disentangle a confident but unsupported explanation from the behaviour that was genuinely observed.
The report would include coverage and remaining questions, not just defects. We may have explored interruption during confirmation but not a dependency outage during batch processing. That distinction prevents an exaggerated statement that payments were comprehensively tested. A potentially serious finding should be escalated immediately rather than wait until the entire session record is polished. The record can then explain which checks are complete and which remain subject to confirmation.
Turn discoveries into proportionate protection
A reproducible issue should be connected to a requirement and a proposed regression check. Not every discovery needs a browser-level automated test. Some rules are more effectively checked at a service boundary or in domain logic. I would choose the level that exposes the risk with a stable and understandable signal. Exploration continues to matter because it helps identify which behaviour deserves repeatable protection and where requirements still need clarification.
I would avoid measuring a tester solely by the number of defects found. A session can be valuable because it clarifies an ambiguous rule or demonstrates correct handling of a risky condition. Conversely, a charter is not proof of coverage; it is an intention. Actual notes establish what happened, which outputs were inspected and which constraints weaken confidence in the conclusion. Review should consider those distinctions rather than reward longer sessions or more dramatic descriptions.
The debrief should classify each surprise as a confirmed defect, an unclear expectation or an environment limitation. I would derive the next charter from a specific gap rather than expand the original session indefinitely. Recording the system version, user role, time zone and interruption conditions makes later investigation possible without pretending that a timing-dependent observation has already been fully explained.
Summary and recommendations
Start with a narrow charter linked to a customer risk, prepare an authorised environment and leave time to reproduce discoveries. Debrief what the team learned, communicate evidence and expectations, and state limitations explicitly. Exploratory testing complements scripted checks by allowing new questions to emerge during investigation. Its quality lies in a defensible and useful insight, rather than the volume of clicks, the number of screenshots or the amount of time spent searching.