Exploratory testing thrives on structured freedom—balancing guided investigation with creative problem-solving. Test charters provide this structure, defining the scope, mission, and focus areas for exploratory sessions while leaving room for tester judgment and serendipitous discoveries. Well-written charters transform ad-hoc testing into a disciplined, repeatable practice that generates valuable insights and comprehensive session documentation.
What is a Test Charter?
A test charter is a concise document (typically 1-2 paragraphs) that outlines:
- Mission: What you’re trying to learn or accomplish
- Scope: What parts of the system to explore
- Resources: Tools, data, documentation needed
- Time: Suggested duration (usually 60-90 minutes)
Unlike scripted test cases with predefined steps, charters provide direction without constraining exploration. They answer: “What should I investigate?” not “Exactly what should I do?”
Anatomy of an Effective Test Charter
Basic Template
Explore: [AREA/FEATURE]
With: [RESOURCES/TOOLS/DATA]
To discover: [RISKS/INFORMATION/BUGS]
Example 1: E-commerce Checkout
Explore: Payment processing flow
With: Multiple payment methods (credit card, PayPal, Apple Pay), various card types (Visa, MasterCard, Amex), edge-case amounts ($0.01, $999,999.99), expired cards
To discover: Validation failures, error handling issues, race conditions in payment confirmation, security vulnerabilities in card data transmission
Example 2: Mobile App Performance
Explore: App behavior under network instability
With: Network Link Conditioner (simulate 3G, Edge, 100% packet loss), Charles Proxy for traffic inspection, device battery at <20%
To discover: Timeout handling, offline mode functionality, data synchronization issues, excessive battery drain, crash scenarios
Extended Charter Format
For complex features, add more detail:
## Charter: Search Functionality Stress Testing
**Mission**: Evaluate search engine performance and resilience under high load and edge cases
**Scope**:
- Product search (catalog of 50,000+ items)
- Advanced filters (price range, category, brand, ratings)
- Search suggestions and autocomplete
- Search history and saved searches
**Test Ideas**:
- Extremely long search queries (>500 characters)
- Special characters and SQL injection attempts
- Unicode and emoji in search terms
- Concurrent searches from same user session
- Rapid-fire typing in autocomplete
- Filters applied in various combinations
**Resources**:
- JMeter script for load generation
- Test dataset with diverse product names
- OWASP ZAP for security testing
- Browser DevTools for performance profiling
**Duration**: 90 minutes
**Risks to Investigate**:
- SQL injection or XSS vulnerabilities
- Poor performance with complex queries
- Autocomplete race conditions
- Memory leaks with repeated searches
- Inconsistent results with same query
**Success Criteria**:
- All searches return within 2 seconds
- No security vulnerabilities found
- Graceful degradation under load
- Clear error messages for invalid queries
Heuristics and Test Triggers
Effective charters incorporate testing heuristics—general principles that guide investigation.
SFDPOT Heuristic (James Bach)
Structure: Test the architecture and relationships
- API endpoints and their integrations
- Database schema and foreign key constraints
- File structures and configuration files
Function: Test what the system does
- Feature functionality as described in requirements
- Business logic and calculations
- Input/output transformations
Data: Test with various data inputs
- Boundary values (min, max, just inside/outside limits)
- Invalid/malformed data
- Large datasets and edge cases
Platform: Test on different environments
- Operating systems (Windows, macOS, Linux)
- Browsers (Chrome, Firefox, Safari, Edge)
- Devices (desktop, mobile, tablet)
Operations: Test user workflows
- Common user journeys
- Multi-step processes
- Concurrency and race conditions
Time: Test timing-related behavior
- Timeouts and delays
- Scheduled jobs and cron tasks
- Date/time edge cases (leap years, DST, timezones)
CAN I USE THIS? Heuristic
Ask these questions when exploring:
- Capability: Does it do what it claims?
- Availability: Is it accessible when needed?
- Reliability: Does it work consistently?
- Compatibility: Does it work with other systems?
- Usability: Can users accomplish tasks easily?
- Performance: Is it fast enough?
- Security: Is data protected?
- Scalability: Can it handle growth?
Applying Heuristics in Charters
Charter: Login Authentication Exploration
Explore: User authentication flow
With: Valid/invalid credentials, SQL injection payloads, XSS attempts, password managers (LastPass, 1Password), multiple browsers
To discover: Security vulnerabilities, usability issues, session management bugs
Using heuristics:
- Structure: Test OAuth integration, session token storage
- Data: Empty fields, very long passwords, unicode characters
- Platform: Test on mobile Safari, desktop Chrome, incognito mode
- Operations: Login → navigate → logout → login again
- Time: Session expiration after 30 min inactivity
Note-Taking During Sessions
Effective documentation happens during the session, not after.
Session Log Template
# Exploratory Session Log
**Charter**: Payment processing flow
**Tester**: John Doe
**Date**: 2024-10-06
**Start Time**: 10:00 AM
**Duration**: 90 minutes
## Setup
- Environment: Staging (v2.3.5)
- Test data: 10 test credit cards, 5 PayPal sandbox accounts
- Tools: Charles Proxy, Browser DevTools
## Timeline
### 10:05 - Credit Card Validation
- Tested Visa, MasterCard, Amex with valid numbers
- ✅ All accepted correctly
- ❌ BUG-1234: Amex CVV validation accepts 3 digits (should require 4)
### 10:20 - Expired Card Handling
- Tested cards expired 1 month ago, 1 year ago, exact current month
- ✅ Clear error message displayed
- ⚠️ QUESTION: Should cards expiring current month be accepted? (Clarify with PO)
### 10:35 - Edge Case Amounts
- $0.01: ✅ Processed successfully
- $999,999.99: ❌ BUG-1235: Server timeout after 30 seconds
- $0.00: ✅ Correctly rejected with "Invalid amount" error
### 10:50 - Network Interruption Simulation
- Enabled "100% packet loss" during payment submission
- ❌ BUG-1236: Payment hung indefinitely, no timeout message
- After restoring network, duplicate charge appeared
- ❌ BUG-1237: No idempotency protection for retried payments
### 11:15 - PayPal Integration
- Tested complete flow: redirect → authenticate → return
- ✅ Successful payment
- ⚠️ OBSERVATION: Redirect URL contains user email in plain text (privacy concern?)
## Bugs Found
1. **BUG-1234**: Amex CVV validation incorrect (High priority)
2. **BUG-1235**: Timeout on very large amounts (Medium)
3. **BUG-1236**: No timeout on network failure (High)
4. **BUG-1237**: Duplicate charges possible (Critical)
## Questions for Team
- Should current-month expiring cards be accepted?
- Is user email in redirect URL a security issue?
- What's the maximum allowed transaction amount?
## Test Coverage
- ✅ Card validation rules
- ✅ Expired card handling
- ✅ Edge-case amounts
- ✅ Network failure scenarios
- ✅ Third-party payment integration
- ❌ Refund processing (out of scope for this session)
- ❌ Concurrent payment attempts (didn't get to it)
## Risks Not Covered
- Testing with real payment processors (only sandbox tested)
- International cards with non-USD currencies
- PCI compliance verification
## Follow-Up Sessions Needed
- Charter: Refund and chargeback processing
- Charter: Payment fraud detection mechanisms
Mind Mapping for Complex Sessions
For features with many interconnected parts, use mind maps:
Authentication
|
+---------------+---------------+
| | |
Login Logout Session Mgmt
| | |
+----+----+ +----+----+ +----+----+
| | | | | | | |
Password Email SSO Manual Timeout Concurrent Expiry
Session Debriefing Reports
After completing a session, create a formal debriefing document for stakeholders.
Debriefing Template
# Exploratory Testing Debriefing Report
**Charter**: Search functionality stress testing
**Session ID**: ET-2024-106-01
**Tester**: Jane Smith (Senior QA Engineer)
**Date**: 2024-10-06
**Duration**: 90 minutes
**Environment**: Staging v2.4.0-rc1
---
## Executive Summary
Conducted exploratory testing of search functionality focusing on performance and security under stress conditions. **Found 3 high-severity bugs** related to SQL injection vulnerability, autocomplete race conditions, and memory leaks. Search performance met criteria for simple queries but degraded significantly with complex filters.
**Overall Risk Assessment**: 🔴 **HIGH** - SQL injection vulnerability blocks release
---
## Test Coverage
### Areas Explored
✅ Basic keyword search
✅ Advanced filtering (price, category, brand)
✅ Search autocomplete and suggestions
✅ Special character handling
✅ Load testing (concurrent users)
✅ Security testing (injection attacks)
### Areas Not Explored (Out of Scope)
❌ Voice search functionality
❌ Image-based search
❌ Search analytics and tracking
---
## Findings
### 🔴 Critical Issues
**BUG-2301: SQL Injection Vulnerability in Search**
- **Severity**: Critical
- **Description**: Search query parameter not sanitized. Input `' OR '1'='1` returns entire product catalog
- **Steps**: Enter `' OR '1'='1` in search box
- **Impact**: Complete database exposure, potential data breach
- **Evidence**: Screenshot attached, Charles Proxy logs saved
- **Recommendation**: **BLOCK RELEASE** until fixed
### 🟠 High Priority Issues
**BUG-2302: Autocomplete Race Condition**
- **Severity**: High
- **Description**: Rapid typing causes autocomplete requests to return out of order, showing suggestions for previous queries
- **Reproduction**: Type quickly: "laptop" → delete → "phone" → observe suggestions still show laptop accessories
- **Impact**: Confusing user experience, potential incorrect selections
- **Frequency**: Reproducible 7/10 attempts
**BUG-2303: Memory Leak in Search Results**
- **Severity**: High
- **Description**: Repeated searches without page refresh cause browser memory to grow indefinitely (from 150MB to 1.2GB after 50 searches)
- **Impact**: Browser slowdown, eventual crash on mobile devices
- **Evidence**: DevTools memory profiler graphs attached
### 🟡 Medium Priority Issues
**BUG-2304: Slow Performance with Multiple Filters**
- **Severity**: Medium
- **Description**: Combining 4+ filters increases response time from <2s to 8-12s
- **Impact**: Poor user experience, potential timeout errors
- **Metrics**: Average 9.5s response time (target: <2s)
---
## Positive Observations
✅ Search handled Unicode and emoji correctly
✅ Error messages were clear and helpful
✅ Graceful degradation when backend is slow
✅ Mobile responsive design worked well
---
## Test Metrics
| Metric | Result |
|--------|--------|
| Bugs Found | 4 (1 Critical, 2 High, 1 Medium) |
| Test Ideas Executed | 18 / 22 planned |
| Coverage (subjective) | ~75% of charter scope |
| Session Efficiency | 4.4 bugs/hour |
---
## Recommendations
1. **Immediate**: Fix SQL injection (BUG-2301) before any release
2. **High Priority**: Address autocomplete race condition and memory leak
3. **Future Enhancement**: Implement query result caching to improve filter performance
4. **Next Session**: Explore search analytics and user behavior tracking
---
## Artifacts
- Session notes: `session-log-ET-2024-106-01.md`
- Screenshots: `evidence/search-testing/`
- Charles Proxy logs: `evidence/search-testing/charles-session.chls`
- Memory profiler data: `evidence/search-testing/memory-profile.json`
---
**Approval**: QA Manager Review Required
**Distribution**: Engineering Team, Product Owner, Release Manager
Charter Libraries and Reusability
Build a repository of charters for recurring test needs.
Charter Categories
Functional Testing Charters:
- User registration and authentication
- Payment processing
- Data import/export
- Report generation
Non-Functional Charters:
- Performance under load
- Security vulnerability assessment
- Accessibility compliance
- Mobile responsiveness
Integration Charters:
- Third-party API integrations
- Database migration scenarios
- Cross-browser compatibility
Charter Templates Repository
charter-library/
├── functional/
│ ├── authentication-charter-template.md
│ ├── payment-processing-charter-template.md
│ └── data-validation-charter-template.md
├── non-functional/
│ ├── performance-testing-charter-template.md
│ ├── security-assessment-charter-template.md
│ └── accessibility-charter-template.md
├── integration/
│ ├── api-integration-charter-template.md
│ └── third-party-services-charter-template.md
└── session-reports/
├── 2024-Q4/
│ ├── session-ET-2024-106-01-report.md
│ └── session-ET-2024-106-02-report.md
└── templates/
├── session-log-template.md
└── debriefing-report-template.md
Integrating Charters into Agile Workflows
Sprint Planning
- Identify high-risk features: Create charters for complex user stories
- Allocate time: Reserve 10-20% of testing time for exploratory sessions
- Assign ownership: Specific testers take specific charters
During Sprint
- Daily sessions: 60-90 minute focused explorations
- Rapid feedback: Report findings in daily standups
- Adapt charters: Refine based on discoveries
Retrospectives
- Review session metrics: Bugs per hour, coverage estimates
- Share learning: Discuss interesting bugs and techniques
- Update charter library: Add new templates, retire outdated ones
Best Practices for Charter Writing
1. Be Specific but Flexible
Poor Charter:
Explore: The application
To discover: Bugs
Good Charter:
Explore: Shopping cart calculation logic with promotional codes, quantity discounts, and tax rules
With: Edge-case combinations (multiple promo codes, expired codes, international tax rules)
To discover: Calculation errors, rounding issues, coupon stacking vulnerabilities
2. Time-Box Sessions
Limit sessions to 60-120 minutes. Longer sessions lose focus and lead to tester fatigue.
3. Use Personas and Scenarios
Charter: Mobile app usability for elderly users
Persona: Margaret, 68, limited tech experience, uses reading glasses
Scenarios:
- First-time app setup and registration
- Finding and purchasing a product
- Accessing customer support
4. Include Risk Hypotheses
Charter: API rate limiting exploration
Hypothesis: Aggressive requests might bypass rate limiting through IP rotation
To test:
- Send 1000 requests/minute from single IP
- Send same load distributed across 10 IPs
- Observe if limits apply per-IP or per-account
5. Document What You Didn’t Test
Explicitly note areas out of scope or not covered. This prevents assumptions about coverage.
Conclusion
Well-crafted test charters transform exploratory testing from unstructured investigation into a disciplined, documentable practice. By providing clear missions, leveraging testing heuristics, maintaining detailed session logs, and producing comprehensive debriefing reports, teams gain the benefits of both exploratory freedom and structured test management.
The key is balance: charters should guide without constraining, document without bureaucracy, and enable creative exploration while ensuring accountability and knowledge transfer. Build a charter library, integrate sessions into your workflow, and continuously refine your approach based on what you learn.