Test Charter Missions: Target, Resources and Information (ISTQB CTAL-TA Experience-Based Testing)
Overview
In the ISTQB Advanced Level Test Analyst (CTAL-TA) syllabus, exploratory testing is presented as a structured, experience-based approach rather than random clicking. The key tool that gives it structure is the test charter. At the heart of every charter is the mission, a short statement of what the session should achieve.
A widely used template for the mission, popularised by Elisabeth Hendrickson in Explore It!, has three parts:
Explore <target>
With <resources>
To discover <information>
This guide explains why the mission matters, what each part means, how to apply it, and how to handle exam questions on it.
1. Why It Is Important
Focus without scripting. Exploratory testing relies on the tester designing, executing and learning at the same time. Without a mission, a session can drift into unfocused activity. The mission keeps the tester on track while still leaving freedom in how to test.
Manageability and accountability. In session-based test management (SBTM), testing happens in uninterrupted, time-boxed sessions. Each session is tied to a charter. This lets test managers plan, prioritise, track and report exploratory work, such as how many charters are done and what was found.
Risk alignment. A well-written mission links exploration to product risks and test objectives. The 'information' part states which risks or quality characteristics the session should shed light on.
Repeatability of intent. The same charter can be given to different testers. They will not follow identical steps, but they will pursue the same goal, which makes results comparable.
Communication. The mission is short enough for stakeholders to understand what is being explored and why. This supports debriefs and test reporting.
Right level of detail. The template helps avoid two common failures. Some charters are too broad, such as 'Test the system'. Others are so detailed they become scripted test cases.
2. What It Is
A test charter is documentation of the goals or objectives of a test session. Its mission describes the purpose of the session in one or two sentences. The three components are:
Target: what to explore.
This is the part of the test object the session focuses on. Examples include:
- a feature, function or user story
- a screen, module, component or interface
- a requirement, business process or workflow
- a quality characteristic in a specific area, such as performance of the search function
Example: 'the checkout and payment workflow'.
Resources: what you will explore with.
These are the means the tester will use. Examples include:
- tools, such as proxy tools, log viewers, browser developer tools or data generators
- test data sets, such as boundary values, invalid inputs, large files or production-like data
- configurations and environments, such as specific browsers, devices or locales
- techniques and heuristics, such as boundary value analysis, attack lists, tours or error guessing
- other people, documents or personas, such as a domain expert, a user role or a requirements document
Example: 'expired, declined and foreign-currency credit cards'.
Information: what you hope to discover.
This is the kind of knowledge the session should produce. It is not a pass/fail verdict but insight. Examples include:
- defects and failure modes
- risks, such as security vulnerabilities or data integrity problems
- behaviour under unusual conditions
- usability or accessibility problems
- whether a requirement or expectation is met
- gaps in requirements or understanding
Example: 'how the system handles payment errors and whether orders are left in an inconsistent state'.
Full example mission:
Explore the checkout and payment workflow with expired, declined and foreign-currency credit cards to discover how payment errors are handled and whether orders are left in an inconsistent state.
Other charter content. Besides the mission, a charter may include further elements. These can be:
- actors or user roles
- purpose or test objectives
- setup and preconditions
- priority
- references, such as specifications, user stories or risk items
- data to use
- activities or ideas
- oracle notes, meaning how to judge correct behaviour
- variations to try
- the time-box duration
The mission is the core of the charter. The other elements support it.
3. How It Works
Step 1: Identify what needs exploring. Use the product risk analysis, user stories, recent changes, defect clusters, or areas where specifications are weak. Each risk area or feature can become a target.
Step 2: Decide the information goal. Ask what stakeholders need to know about the target. Examples are security weaknesses, robustness, usability or correctness of calculations. This keeps the session tied to test objectives.
Step 3: Choose resources. Select the tools, data, techniques, heuristics and environments that make discovering that information most likely. For example:
- to look for injection vulnerabilities, use an attack list and a proxy tool
- to check localisation, use different locale settings
Step 4: Calibrate scope. A good mission fits a single time-boxed session, typically 60 to 120 minutes.
- If the target is too broad, split it into several charters.
- If the resources are so specific that the mission dictates exact steps, loosen it so the tester can still explore.
Step 5: Execute the session. The tester explores within the mission. They take notes on what was tested, issues found, questions raised and new ideas. Ideas outside the mission are noted as candidate new charters rather than pursued at length.
Step 6: Debrief. The tester and test manager or lead review the session sheet. They discuss what information was discovered, whether the mission was fulfilled, and what follow-up charters are needed.
Too broad, too narrow, about right:
- Too broad: 'Explore the application to find bugs.' There is no real target, resources or information goal.
- Too narrow: 'Enter 0, 1, 99 and 100 in the quantity field and verify error message E12.' This is a scripted test case, not an exploration.
- About right: 'Explore the quantity field on the order form with boundary values and non-numeric input to discover how input validation and error messaging behave.'
4. Mapping Component Words to Their Role
The exam often hides the three components in a scenario. Use these cues:
Target words: feature, module, screen, function, workflow, interface, user story, requirement, area, component. Ask yourself: what part of the system?
Resource words: using, with, tool, data set, browser, device, technique, heuristic, persona, configuration, attack list, checklist. Ask yourself: what will help me test it?
Information words: to discover, to find out, to learn, to evaluate, risks, vulnerabilities, defects, behaviour, whether, how. Ask yourself: what do we want to know?
5. Common Misconceptions
- The information part is not the expected result. Charters target discovery, not confirmation of a single predefined output.
- Resources are not the target. 'Explore Chrome' is wrong when Chrome is the environment being used to test a web feature. Chrome is a resource.
- Techniques can be resources. Boundary value analysis, state transition ideas, tours and error-guessing attack lists can all be resources within an exploratory mission.
- A charter is not a test procedure. It guides, but it does not prescribe steps.
- Exploratory testing with charters is not unstructured. Charters, time-boxes, session sheets and debriefs make it manageable and measurable.
- Charters are not only for experts. They help less experienced testers too, by giving them clear focus.
6. Exam Tips: Answering Questions on Test Charter Missions: Target, Resources and Information
Tip 1: Memorise the template. Explore <target> with <resources> to discover <information>. Many questions simply ask which part of a given mission is which.
Tip 2: Classify each phrase in the scenario. When a question gives a mission or scenario, mentally label each phrase as T (target), R (resources) or I (information). Then eliminate the options that mislabel them.
Tip 3: Look for the 'with' and 'to discover' signals. Text after 'with' or 'using' is usually a resource. Text after 'to discover', 'to find', 'to learn' or 'to evaluate' is usually information. The object right after 'explore' is the target.
Tip 4: Watch for swapped components. A distractor might call a tool or browser the target, or call a feature the information. Always ask whether the item is the thing being tested, the means of testing, or the knowledge sought.
Tip 5: Pick the best-scoped charter. In 'Which is the best charter?' questions, choose the option that:
- has a clear, focused target
- names useful resources
- states meaningful, risk-related information to discover
- fits a time-boxed session
Reject vague options, such as 'test everything', and scripted options with exact steps and expected values.
Tip 6: Link the information to risk. For K3 application questions, the correct charter usually addresses the risk mentioned in the scenario. For example, if the scenario stresses data privacy, the information part should be about exposure of personal data.
Tip 7: Match resources to the information goal. A good answer pairs sensible resources with the goal, such as security attack lists for vulnerabilities or different screen readers for accessibility. A mismatch, such as a load tool to discover spelling errors, signals a distractor.
Tip 8: Remember the SBTM context. Questions may mix charters with session-based test management. Know these points:
- sessions are time-boxed and uninterrupted
- each session has one charter
- notes are recorded on session sheets
- debriefs review findings and generate new charters
Tip 9: Distinguish charters from test cases and checklists. If an option describes detailed steps with expected results, it is a test case, not a charter mission. Checklist-based testing uses a list of conditions. A charter states a mission for exploration.
Tip 10: Read the qualifiers. Words like 'most appropriate', 'best', 'primary' or 'NOT' change the answer. Several options may be plausible. Choose the one that most fully fits the target, resources and information structure and the scenario's stated objective.
Tip 11: Out-of-scope ideas become new charters. If a question asks what a tester should do when they spot an interesting area outside the mission, the expected answer is usually to note it and propose a new charter. They should not abandon the current mission.
Quick Practice Example
Mission: 'Explore the user registration API with malformed JSON payloads and a REST client to discover how the service handles invalid input and whether it leaks stack traces.'
- Target = the user registration API
- Resources = malformed JSON payloads and a REST client
- Information = how invalid input is handled and whether stack traces are leaked, which is a security and robustness risk
Summary
The test charter mission turns exploratory testing into a focused, manageable activity.
- The target says where to look.
- The resources say what to use.
- The information says what you want to learn.
In the exam, identify each component confidently, spot swapped or badly scoped options, and choose charters whose resources and information goals fit the risks in the scenario.
