A tester sits down at her desk, coffee in hand, and opens the application. “I’m going to do some exploratory testing on the checkout flow,” she announces. Two hours later, her manager asks what she found. She pauses. She tested… things. She clicked around. She found a weird layout issue on the cart page, spent twenty minutes trying to reproduce a tooltip glitch that turned out to be her browser, and eventually got pulled into investigating whether the discount code field handles SQL injection. She can’t quite articulate what she covered, what she skipped, or whether the checkout flow is actually trustworthy.
Now picture a different tester. Same application, same checkout flow. But before she opens the browser, she writes a single sentence: Explore the checkout flow with multiple discount codes applied simultaneously, using accounts with different membership tiers, to discover whether pricing calculations remain accurate under combination scenarios. Forty-five minutes later, she’s found three genuine pricing bugs, documented exactly what she tested, and can confidently say which scenarios she covered and which still need attention.
The difference isn’t skill or experience. It’s a charter.
Test charters are the unsung workhorses of effective exploratory testing. They’re deceptively simple — often just a sentence or two — but they represent the critical line between exploration that discovers meaningful problems and aimless clicking that wastes everyone’s time. In our previous article on Session-Based Test Management, we introduced charters as the mission statements that launch each session. Now it’s time to master the craft of writing them. Because a charter isn’t just a label you slap on a session — it’s the decision that determines whether the next 90 minutes of testing will be focused, productive, and communicable, or scattered and forgettable.
This article is about writing charters that actually work — ones that focus your attention, guide your decisions in the moment, and produce results you can communicate clearly when the session ends.
What a Charter Actually Is (And Isn’t)
A test charter is a brief statement that defines the mission of an exploratory testing session. It answers three fundamental questions: What are you testing? How are you testing it? What are you looking for?
That’s it. Not a test plan. Not a requirements document. Not a script with predetermined steps. A charter is a compass heading — it tells you which direction to walk, but it doesn’t dictate every step.
This distinction matters because testers frequently confuse charters with other artifacts. A charter is not a test case with its steps removed. It’s not a vague aspiration like “test the login page.” And it’s not a detailed specification that leaves no room for judgment. It lives in a specific zone between too loose and too tight.
Think of it this way: if your “charter” could be executed identically by any two testers, it’s probably a script. If your “charter” could lead two testers to test completely different features with zero overlap, it’s probably too vague. A well-written charter will lead different testers through similar territory while allowing each to bring their own instincts, observations, and investigative paths to the work.
The power of a charter is in what it excludes as much as what it includes. By defining a focus area, you’re implicitly saying “not that other stuff — at least not right now.” This constraint is liberating. It frees the tester from the anxiety of trying to test everything and lets them go deep on something specific.
The Anatomy of an Effective Charter
In our SBTM article, we introduced charters as mission statements answering what, why, and what’s in scope. Now let’s get precise about structure. The most widely used charter format comes from James Bach’s work on exploratory testing, and it follows a three-part template:
Explore (target) with (resources) to discover (information).
Each component plays a specific role. The target identifies what part of the system you’re testing. The resources describe the tools, techniques, data, or approaches you’ll use. The information specifies what kind of findings you’re after — what questions you’re trying to answer.
Here’s a concrete example: Explore the user profile editing page with boundary values and special characters in all text fields to discover input validation weaknesses and error handling gaps.
Let’s break that apart. The target is specific — not “the user module” but “the user profile editing page.” The resources are defined — boundary values and special characters, which tells the tester what techniques to employ. The information goal is clear — we’re hunting for validation weaknesses and error handling gaps, not performance issues or visual bugs (though if those appear, they’re still worth noting).
Compare that to a weak charter: Test user profiles. This tells the tester almost nothing. Which aspect of user profiles? Using what approach? Looking for what? A tester receiving this charter has to make all the important decisions on their own, which defeats the purpose of having a charter at all.
Now compare it to an overly rigid charter: Navigate to the profile page, enter exactly 256 characters in the first name field, verify an error appears, then enter a script tag in the bio field and verify it’s sanitized. This isn’t a charter — it’s a test case pretending to be one. There’s no room for the tester to follow interesting leads or apply their own judgment.
Charter Scope: The Goldilocks Problem
Getting the scope right is the hardest part of charter writing. Too narrow and you’ve written a test case. Too broad and you’ve written a wish. The goal is a scope that can be meaningfully explored in a single session — typically the 60 to 120 minute window we established in our SBTM framework.
Here’s a practical test: read your charter and imagine starting the session. Can you picture at least five or six different things you’d try? If not, the charter might be too narrow. Can you imagine spending an entire week on it and still not being done? If so, it’s too broad.
Too broad: Explore the application to discover bugs. This isn’t a charter; it’s a job description.
Too broad: Explore the e-commerce platform with various user types to discover usability issues. Which part of the platform? What do you mean by “various”? What kinds of usability issues?
Too narrow: Explore the login page by entering “admin” as username and “password” as password to discover if default credentials work. This is a single test case, not a session charter.
Just right: Explore the login and authentication flow with expired, revoked, and near-expiration credentials to discover how the system communicates authentication failures to users.
That last one works because it defines a focused area (login and authentication), specifies an approach (various problematic credential states), and names a clear information goal (communication of failures). A tester could spend 90 minutes on this and explore dozens of scenarios while staying focused on a coherent theme.
One useful heuristic: a well-scoped charter should generate a mental list of “oh, and I should also try…” moments when you read it. If reading the charter sparks ideas about variations, edge cases, and what-ifs, the scope is working. If it sparks only one obvious action or an overwhelming flood of unrelated possibilities, adjust accordingly.
Writing Charters for Different Testing Goals
Not all testing sessions have the same objective, and your charters should reflect this. Different goals demand different charter structures.
Risk-Based Charters
When you know where the danger is, write charters that target it directly. Risk-based charters focus on areas where failures would cause the most damage or where changes have introduced the most uncertainty.
Explore the payment processing flow with international credit cards and currency conversion to discover calculation accuracy issues that could result in incorrect charges.
Notice how this charter connects the testing activity directly to business risk. The tester isn’t just finding bugs — they’re investigating a specific category of failure that has real financial consequences.
Technique-Based Charters
Sometimes you want to apply a specific testing technique systematically across a feature area. These charters lead with the method.
Explore the appointment scheduling calendar with state transition analysis — moving appointments through every possible status change sequence — to discover states that become unreachable or transitions that corrupt data.
The technique (state transition analysis) drives the session while the target and goal keep it focused.
User-Scenario Charters
These simulate real-world usage patterns, often combining multiple features the way actual users would.
Explore the end-to-end order process as a returning customer with saved payment methods and address book entries, using a mix of in-stock and backordered items, to discover workflow friction and data consistency issues across the purchase journey.
These tend to be broader in scope but are held together by the coherence of the user story.
Regression-Focused Charters
After changes to the codebase, you need charters that explore the blast radius of those changes. This aligns naturally with the progressive coverage model from SBTM — these charters typically come in the follow-up and confirmation phases.
Explore features adjacent to the recently refactored inventory service — product display, cart calculations, and order confirmation — with scenarios that trigger real-time inventory checks to discover integration failures or behavior changes introduced by the refactoring.
The “To Discover” Clause: Where Most Charters Fail
If there’s one place charters consistently break down, it’s the information goal. Testers nail the target and resources but then write vague discovery clauses that don’t actually guide the session.
Consider these two charters:
Explore the search functionality with long and complex queries to discover bugs.
Explore the search functionality with long and complex queries to discover how the system degrades — whether it slows down, truncates input, returns irrelevant results, or fails silently — as query complexity increases.
The first charter sends the tester out with a butterfly net, hoping to catch something. The second charter tells the tester exactly what to observe and what degradation patterns to look for. Both testers might find the same bugs, but the second tester will find them faster, describe them more precisely, and recognize subtle issues that the first tester might dismiss.
Strong discovery clauses share a few characteristics. They name specific types of information, not just “bugs” or “issues.” They describe observable behaviors the tester should watch for. And they frame the investigation as a question the session should answer, even if the answer turns out to be “everything works fine here.”
Here are some transformations from weak to strong:
Weak: …to discover problems. Strong: …to discover whether error messages accurately describe what went wrong and guide the user toward resolution.
Weak: …to discover if it works. Strong: …to discover how the system behaves when the user’s session expires mid-transaction — whether data is preserved, lost, or partially saved.
Weak: …to discover security issues. Strong: …to discover whether authenticated API endpoints properly reject requests with manipulated user IDs, expired tokens, or privilege escalation attempts.
The pattern is consistent: strong discovery clauses describe what you’ll observe and what patterns you’re looking for, not just what category of problem you hope to find.
Writing Charters from Different Sources
Charters don’t materialize from thin air. They’re derived from information you already have — you just need to know how to translate that information into focused missions.
From Requirements and User Stories
Take a user story like: As a user, I want to reset my password so I can regain access to my account.
A requirements-based charter might be: Explore the password reset flow with various account states — locked, unverified, recently changed password, multiple failed reset attempts — to discover edge cases where users get stuck without a path back to their account.
The charter goes beyond verifying the happy path. It uses the requirement as a starting point but then asks: what could go wrong for real users in real situations?
From Bug Reports
Previous bugs are gold mines for charter writing. A bug report about a timezone issue in scheduling might generate: Explore the appointment scheduling system with users in different timezones, including half-hour offset zones and daylight saving transition dates, to discover whether time display and calculation remain consistent across all timezone scenarios.
From Production Data and Analytics
If your analytics show that 15% of users abandon the checkout flow at the shipping address step, that’s a charter waiting to happen: Explore the shipping address entry and validation step with international addresses, autofill tools, and address correction scenarios to discover friction points that could explain the high abandonment rate at this step.
From Code Changes
This source connects directly to the charter backlog concept from SBTM. As code changes come in, they should generate charters that feed into your session planning. A pull request touching the notification service suggests: Explore all notification-triggering events — order confirmation, shipping updates, password changes, account alerts — to discover whether notifications fire correctly, contain accurate information, and handle delivery failures gracefully after the recent notification service updates.
Charter Decomposition: Breaking Big Ideas Into Testable Sessions
One of the most common charter-writing mistakes is trying to cram too much into a single session. “Explore the entire admin panel” isn’t a charter — it’s a project. You need to decompose large testing areas into multiple focused charters that together provide comprehensive coverage.
The decomposition process follows a natural hierarchy. Start with the broad area, identify its major aspects, and then write individual charters for each at a scope appropriate for a single session.
Take “test the reporting module” as a starting point. You might decompose it like this:
Charter 1: Explore report generation with the maximum data range (full year, all departments) to discover performance limits and timeout behavior under heavy data loads.
Charter 2: Explore report filtering and parameter combinations — applying multiple filters simultaneously, using conflicting date ranges, selecting then deselecting options — to discover whether filter interactions produce accurate or misleading results.
Charter 3: Explore report export functionality across all formats (PDF, CSV, Excel) with reports containing special characters, large datasets, and complex formatting to discover data fidelity and formatting issues in exported files.
Charter 4: Explore report scheduling and automated delivery with various recipient configurations, timezone settings, and frequency options to discover reliability and accuracy of the automation features.
Each charter is a focused, session-sized mission. Together, they provide thorough coverage of the reporting module. Individually, each one gives a tester clear direction and purpose. And when tracked on your SBTM session sheet, these four charters give your team a clear picture of how thoroughly the reporting module has been explored.
A useful decomposition strategy is to think in dimensions: data dimensions (volume, variety, edge cases), user dimensions (roles, permissions, experience levels), technical dimensions (browsers, devices, network conditions), and workflow dimensions (common paths, alternative paths, error paths). Each dimension can generate its own charter or set of charters.
Charters and AI-Generated Code: A Modern Necessity
Here’s where charter writing becomes particularly urgent. When code is generated or heavily assisted by AI tools, the assumptions baked into that code may be subtly wrong in ways that scripted test cases — often generated by the same AI — won’t catch. Charter-based exploratory testing becomes your best defense against correlated failures between AI-generated code and AI-generated tests.
Consider this scenario: a development team uses an AI assistant to generate a new user registration flow and then uses the same or similar AI to generate test cases. The AI’s model of “how registration should work” will be internally consistent — the tests will validate the code’s behavior even if that behavior doesn’t match actual business rules, edge cases, or user expectations. Both the code and the tests share the same blind spots.
A well-written exploratory charter breaks this pattern by bringing human judgment, domain knowledge, and genuine curiosity to the testing process. An effective charter for AI-generated code might look like: Explore the AI-generated registration flow with real-world input patterns — names with hyphens and apostrophes, international phone formats, corporate email domains with strict validation — to discover assumptions the AI made about user data that don’t match actual usage.
When writing charters specifically for AI-generated features, focus your “to discover” clause on assumptions and unstated requirements — the things AI tools handle well in the average case but often get wrong at the margins.
Common Charter Anti-Patterns
Knowing what bad looks like helps you avoid writing it. Here are the patterns that consistently produce ineffective charters.
The Everything Charter: Explore the application with all testing techniques to discover all types of issues. This isn’t focus — it’s the absence of focus wearing a charter’s clothing. If your charter could apply to literally any software product, it’s too generic.
The Predetermined Outcome: Explore the login page to discover that it rejects invalid passwords. This isn’t exploration — it’s a pass/fail check. If you already know what you expect to find, you’ve written a test case, not a charter.
The Tool Charter: Explore the application with Postman to discover API issues. The tool isn’t the point. What are you trying to learn? Explore the user-facing workflows while monitoring corresponding API calls in Postman to discover discrepancies between what the UI shows and what the API actually returns. Now the tool serves the mission rather than defining it.
The Vague Wanderer: Explore some parts of the settings page. Which parts? Why? Looking for what? This charter provides no more guidance than “go test stuff.”
The Scope Creeper: A charter that starts focused but includes “also check” clauses that expand it beyond a single session. Explore the search function with special characters to discover input handling issues. Also check pagination, sorting, filter combinations, and performance under load. That’s four charters masquerading as one.
From Charter to Session: The Handoff
Understanding how a charter translates into action helps you write better ones.
When a tester picks up a well-written charter, their mental process should go something like this: First, they read the target and orient themselves — opening the right part of the application, setting up the right environment or test data. Then they read the resources clause and begin planning their first few moves — what inputs they’ll try, what tools they’ll set up, what conditions they’ll create. Finally, they internalize the discovery clause so they know what to observe, what to document, and what patterns to watch for as they explore.
During the session, the charter acts as a gentle constraint. When the tester discovers something interesting but tangential — say, they’re testing search behavior and notice a visual glitch in the header — the charter helps them make a quick decision: note it, log a brief observation, and return to the mission. Without a charter, that glitch might lead to twenty minutes of unplanned CSS investigation.
This is a critical point: charters don’t forbid you from noticing things outside your scope. They give you a framework for deciding how much time to invest in unexpected findings. You might spend two minutes confirming the glitch is reproducible and noting it for a future session, then return to your charter’s focus. That’s discipline informed by flexibility — exactly what good exploratory testing looks like.
The charter also shapes how you document as you go. The session notes you capture — which feed into the session reports we covered in our SBTM article — naturally organize around the charter’s structure. What you tested maps to the target and resources. What you found maps to the discovery clause. What’s left maps to the aspects of the charter you didn’t reach. This alignment isn’t accidental — it’s one of the strongest arguments for investing time in charter quality.
Building a Charter Library
Over time, your team should build a library of effective charter patterns that can be adapted and reused. This isn’t about running the same sessions repeatedly — it’s about having proven templates you can customize for new features and contexts.
A useful charter library is organized by testing concern rather than by feature:
CHARTER LIBRARY CATEGORIES
===========================
INPUT VALIDATION PATTERNS
- Boundary values in [target fields]
- Special characters and encoding in [target]
- International/localized data in [target]
STATE AND WORKFLOW PATTERNS
- Interrupted transactions in [target flow]
- State transition coverage in [target]
- Concurrent user actions in [target]
INTEGRATION PATTERNS
- Data consistency across [system A] and [system B]
- API/UI behavior alignment in [target feature]
- Third-party service failure handling in [target]
PERFORMANCE AND RESILIENCE PATTERNS
- Behavior under slow/intermittent connectivity in [target]
- Large data volume handling in [target]
- Resource exhaustion scenarios in [target]
USER EXPERIENCE PATTERNS
- First-time user journey through [target]
- Error recovery paths in [target]
- Accessibility and assistive technology in [target]Each pattern becomes a template. When a new feature ships, you pull relevant patterns, fill in the specific target and discovery details, and you have a set of focused charters ready to go. This dramatically reduces the overhead of charter writing and ensures consistent coverage across features — feeding directly into the coverage mapping and tracking that SBTM provides.
A Practical Charter-Writing Exercise
Here’s something you can do right now to build your charter-writing skill. Pick any feature in an application you test regularly. Set a timer for ten minutes. Write five charters for that feature, each targeting a different dimension of quality.
Use this template to get started:
CHARTER WRITING EXERCISE
=========================
Feature/Area: ________________________________________
Date: ________
CHARTER 1 - Functionality Focus
Explore _________________ with _________________
to discover _________________
CHARTER 2 - Data/Input Focus
Explore _________________ with _________________
to discover _________________
CHARTER 3 - User Experience Focus
Explore _________________ with _________________
to discover _________________
CHARTER 4 - Error Handling Focus
Explore _________________ with _________________
to discover _________________
CHARTER 5 - Integration/Boundary Focus
Explore _________________ with _________________
to discover _________________
SELF-REVIEW
-----------
For each charter, check:
[ ] Could I start this session right now and know what to do?
[ ] Is the scope achievable in 60-90 minutes?
[ ] Would two different testers cover similar ground?
[ ] Is the discovery clause specific about what to observe?
[ ] Does it leave room for the tester’s judgment and instincts?After writing your five charters, read each one and ask: if I handed this to a colleague with no other context, could they run a productive session? If the answer is no, revise until it’s yes.
Charters as Communication Tools
Beyond guiding sessions, charters serve a vital communication function. When a manager asks “what are we testing this sprint?” a set of well-written charters provides a clearer answer than “we’re doing exploratory testing on the new features.”
Compare these two responses to “what testing is planned?”
Response A: “We’re going to explore the new dashboard.”
Response B: “We have six sessions planned. Charter 1 targets the data refresh mechanism under heavy load. Charter 2 explores widget configuration with conflicting display settings. Charter 3 examines role-based access across the five user permission levels. Charters 4 through 6 cover the export, sharing, and notification features respectively.”
Response B demonstrates planning, communicates scope, and builds confidence that testing will be thorough. The charters themselves become a lightweight test plan that stakeholders can review, question, and influence. “I notice you don’t have a charter for offline behavior — that’s a big concern for our mobile users” is exactly the kind of feedback that charters make possible.
This connects to a point we made in the SBTM article about stakeholder communication: different audiences need different levels of detail. Your charter backlog gives developers specific focus areas, gives product managers coverage visibility, and gives executives confidence that testing is systematic. The charters are the same — the conversation around them adapts to the audience.
Start Writing Better Charters Tomorrow
Charter writing is a skill, which means it improves with practice. You don’t need permission, process changes, or new tools. You just need to write a charter before your next exploratory session and notice the difference it makes.
Start with the template: Explore [target] with [resources] to discover [information]. Make each component specific enough to guide action and flexible enough to allow discovery. Read it back and ask whether you could hand it to a peer and have them run a productive session. If the answer is yes, you have a charter. If the answer is no, sharpen it until you do.
The difference between a tester who writes good charters and one who doesn’t isn’t the bugs they find today — it’s the consistency, communicability, and cumulative coverage they build over weeks and months. Good charters make good sessions. Good sessions, tracked through the SBTM framework, make good testing. And good testing is what stands between your users and the bugs that would otherwise reach them undetected.
In our next article, we’ll explore Ad-Hoc Testing Done Right — why unstructured testing has a legitimate place in your strategy and how to ensure it adds value instead of chaos. After two articles on structured approaches to exploratory testing, we’ll make the case that sometimes the most productive thing a tester can do is throw away the charter entirely — but only if they know when and how.
Remember: A charter isn’t a constraint on exploration — it’s what transforms wandering into discovery.