Additional Information in a Test Charter: A Complete Guide for the ISTQB CTAL-TA Exam
Introduction
In the ISTQB Advanced Level Test Analyst (CTAL-TA) syllabus, exploratory testing is one of the main experience-based test techniques. It is often managed through session-based test management (SBTM), and the central artifact of every session is the test charter.
At its simplest, a charter states the mission of a session. The syllabus also lists additional information that a charter may contain. This extra detail turns a vague instruction into a focused, traceable and reviewable piece of testing work. This guide explains what that information is, why it matters, how it is used, and how to handle exam questions about it.
1. What Is a Test Charter?
A test charter is a short document that guides one exploratory test session. A session is typically a time-boxed period of uninterrupted testing, often 60 to 120 minutes.
The charter tells the tester what to explore and why. It does not prescribe step-by-step actions the way a scripted test case does. A classic minimal charter follows this pattern:
Explore [target] with [resources] to discover [information].
The CTAL-TA syllabus goes further. It recognises that a charter can carry richer supporting information so that sessions are better prepared, prioritised and evaluated.
2. What Is the Additional Information in a Test Charter?
The syllabus lists the following elements that a test charter may contain:
Actor: The intended user of the system, for example an administrator, a first-time customer or a clerk with limited rights. The tester takes on this role during the session.
Purpose: The theme of the charter, including the specific objective the actor wants to achieve. This is the test condition or goal being explored.
Setup: What needs to be in place before test execution can start. Examples are environment configuration, user accounts, installed builds and tools.
Priority: The relative importance of the charter. It is based on the priority of the associated test basis or on the risk level.
Reference: The specifications or sources the charter is linked to, such as user stories, requirements, risks or other information sources. This provides traceability.
Data: Whatever data is needed to carry out the charter, such as test accounts, sample files, boundary values or production-like datasets.
Activities: A list of ideas of what the actor may want to do with the system. These are test ideas, not scripted steps.
Oracle notes: How to evaluate the product to determine correct results. Examples are expected behaviour, comparison with a previous version, consistency heuristics or business rules.
Variations: Alternative actions and evaluations that complement the ideas listed under Activities. Examples are different paths, unusual inputs, interruptions and error conditions.
A useful memory aid: A P S P R D A O V. One way to remember it is Actors Plan Setup, Prioritise References, Data, Activities, Oracles, Variations.
Note on syllabus versions: Newer syllabus versions phrase charter content more generally. They mention items such as the test objective, test conditions, test basis references, test data, environment, time box and heuristics. The underlying ideas are the same: who, what, why, with what, how to judge results and how important.
3. Why Is This Additional Information Important?
Focus without scripting: Activities and Variations give direction while keeping the creative freedom that makes exploratory testing effective.
Risk-based prioritisation: The Priority field lets test managers schedule high-risk charters first, in line with risk-based testing.
Traceability and coverage: References link sessions to user stories, requirements or risks. This makes it possible to report coverage, a common criticism of unmanaged exploratory testing.
Efficiency: Setup and Data prevent wasted session time. Testers do not spend half of a 90-minute session creating accounts or hunting for test files.
Better defect detection: Oracle notes help testers recognise failures. Without an oracle, a tester may observe incorrect behaviour and not realise it is wrong.
Realistic usage: The Actor field encourages testing from a real user perspective, revealing usability and permission issues.
Reproducibility and accountability: A well-documented charter supports the debriefing, metrics and audit needs of session-based test management.
Knowledge transfer: Less experienced testers can perform sessions designed by experts, because the charter captures the expert's thinking.
4. How It Works in Practice
Step 1, Identify test conditions and risks: The Test Analyst analyses the test basis and the risk analysis to decide which areas need exploratory sessions.
Step 2, Write the charters: For each area, a charter is created with the purpose, actor, references, priority and so on.
Step 3, Prioritise and schedule: Charters are ordered by Priority, so high-risk ones run first.
Step 4, Prepare: The Setup and Data items are arranged before the session begins.
Step 5, Execute the session: The tester explores, using Activities as a starting point and Variations to dig deeper. Oracle notes are used to judge outcomes. Notes, defects, issues and new test ideas are recorded.
Step 6, Debrief: After the session, tester and test manager review results. Session sheets typically record the tester, date, start time, duration, charter, coverage, defects, issues, and the split of time between testing, investigation and setup. New charters may be created from the findings.
Example charter
Actor: Registered customer with a saved credit card.
Purpose: Explore the checkout process to discover failures when applying discount codes.
Setup: Build 4.2 deployed to the test environment, payment gateway in sandbox mode.
Priority: High, because revenue-critical and flagged as high risk.
Reference: User story US-118 (Apply promo code), risk R-07.
Data: Valid, expired, single-use and case-variant promo codes, and a basket of 1 to 50 items.
Activities: Apply a code, remove it, apply two codes, change basket contents after applying a code.
Oracle notes: Total must equal the sum of items minus the discount per business rule BR-12, with no negative totals, and the confirmation email must match the on-screen total.
Variations: Use browser back and refresh mid-checkout, let the session time out, use a mobile device, try lower- or upper-case codes.
5. Relationship to Other Concepts
Scripted testing: Charters give guidance, not step-by-step instructions. Activities are ideas, not test procedures.
Checklist-based testing: A checklist may feed the Activities or Oracle notes, but a charter is session-oriented and time-boxed.
Risk-based testing: Priority and Reference connect charters directly to the risk register.
Test oracles: Oracle notes are a direct application of the oracle concept within exploratory testing.
Exam Tips: Answering Questions on Additional Information in a Test Charter
Tip 1, Memorise the list and its definitions: Expect questions such as Which of the following is NOT typically included in a test charter? Know the nine items: Actor, Purpose, Setup, Priority, Reference, Data, Activities, Oracle notes, Variations.
Tip 2, Match the field to its description: Questions often describe content and ask which field it belongs to.
How to evaluate whether results are correct means Oracle notes.
Alternative actions and evaluations means Variations.
What must be in place before starting means Setup.
The intended user means Actor.
User story or risk the charter is linked to means Reference.
Relative importance based on risk means Priority.
Tip 3, Spot the distractors: Wrong answers often describe scripted testing artifacts. Watch for detailed step-by-step test procedures, exact expected results for each step, pass/fail criteria for every action or defect report IDs. A charter contains ideas and guidance, not rigid scripts. Also note that defects found and time spent belong to the session sheet or debrief, not the charter written beforehand.
Tip 4, Distinguish Activities from Variations: Activities are the main ideas of what the actor does. Variations are alternatives that complement those activities, such as unusual paths, error conditions and different inputs.
Tip 5, Link Priority to risk: If a question asks how charters should be ordered, the answer involves Priority based on the risk level or the priority of the test basis.
Tip 6, Connect References to traceability: If a scenario says stakeholders cannot see what requirements exploratory testing covered, the remedy is to add References to user stories, requirements or risks in the charters.
Tip 7, Use scenario clues: In K3 or K4 scenario questions, identify the problem first. Wasted session time points to missing Setup or Data. Testers missing failures points to missing Oracle notes. Shallow testing points to missing Variations. Wrong user perspective points to the Actor.
Tip 8, Remember the SBTM context: Charters are used in time-boxed sessions, often 60 to 120 minutes, followed by a debriefing. Questions may combine charter content with session management concepts.
Tip 9, Read the wording carefully: The syllabus says a charter may contain this information. Answers claiming a charter must contain everything, or must not contain references, are likely incorrect.
Tip 10, Eliminate systematically: When unsure, remove options that contradict the exploratory spirit, such as full scripting or fixed expected outputs per step. Then choose the option that best supports focus, preparation, evaluation or traceability.
Summary
The additional information in a test charter (Actor, Purpose, Setup, Priority, Reference, Data, Activities, Oracle notes and Variations) gives exploratory testing structure without removing its flexibility. It enables risk-based prioritisation, traceability, efficient preparation and reliable evaluation of results. For the exam, know each element and its meaning, recognise scripted-testing distractors, and map scenario problems to the missing charter element.
