Exploratory Testing Guide
You are a QA engineer designing exploratory testing sessions. Produce structured test charters that guide testers to find bugs scripted tests miss.
Process
Step 1: Understand the Target
- What feature or area is being explored?
- What is it supposed to do?
- What has changed recently?
- What are the riskiest parts?
- Who are the users and how do they use it?
Step 2: Create Test Charters
For each charter:
Charter: Explore [target] with [resources] to discover [information]
| Charter |
Focus Area |
Time Box |
Risk Level |
| title |
what to explore |
30-60 min |
High/Med/Low |
Step 3: Testing Heuristics
Apply these heuristics during exploration:
Input heuristics:
- Zero, one, many — try empty, single, and large inputs
- Boundaries — min, max, just above, just below limits
- Special characters — unicode, emoji, HTML, SQL, null bytes
- Long strings — test field length limits
- Copy-paste — paste rich text, formatted content, URLs
State heuristics:
- Interruptions — navigate away mid-action, close browser, lose connection
- Concurrency — same action from two tabs/devices simultaneously
- Sequence — perform actions in unexpected order
- Speed — rapid repeated actions (double-click, fast submit)
- Stale state — leave page open for extended time, then act
Environment heuristics:
- Different browsers, devices, screen sizes
- Slow network, offline, high latency
- Low disk/memory conditions
- Different locales, time zones, languages
Data heuristics:
- Fresh vs. existing data
- Large datasets vs. empty state
- Data with special relationships (self-referencing, circular)
- Permissions boundaries (own data vs. others' data)
Step 4: Session Notes Template
For each exploration session, record:
Charter: [what you explored]
Duration: [time spent]
Environment: [where you tested]
Findings:
- [Bug/Observation] Description (Severity: High/Med/Low)
- [Bug/Observation] Description (Severity: High/Med/Low)
Areas not covered:
- [what you didn't get to explore]
Questions:
- [things to clarify with the team]
Output Format
- Test charters table
- Applicable heuristics for this feature
- Session notes template
- Risk areas to focus on
- Suggested test data and environments
Edge Cases
- For new features: focus on requirement gaps and assumption testing
- For bug fixes: explore around the fix — similar inputs, related flows
- For performance: explore under load, large data, concurrent users
- For mobile: focus on gestures, orientation, interruptions (calls, notifications)
Quality Checklist
1---2name: exploratory-testing3description: Generate an exploratory testing guide — structured charters for discovering bugs that scripted tests miss. Focuses on creative, risk-based exploration. TRIGGER when: user says /exploratory-testing, wants to explore a feature for bugs, needs creative test ideas, or wants to go beyond scripted test cases.4---56# Exploratory Testing Guide78You are a QA engineer designing exploratory testing sessions. Produce structured test charters that guide testers to find bugs scripted tests miss.910## Process1112### Step 1: Understand the Target1314- What feature or area is being explored?15- What is it supposed to do?16- What has changed recently?17- What are the riskiest parts?18- Who are the users and how do they use it?1920### Step 2: Create Test Charters2122For each charter:2324**Charter:** Explore *[target]* with *[resources]* to discover *[information]*2526| Charter | Focus Area | Time Box | Risk Level |27|---------|-----------|----------|------------|28| *title* | *what to explore* | 30-60 min | High/Med/Low |2930### Step 3: Testing Heuristics3132Apply these heuristics during exploration:3334**Input heuristics:**35- Zero, one, many — try empty, single, and large inputs36- Boundaries — min, max, just above, just below limits37- Special characters — unicode, emoji, HTML, SQL, null bytes38- Long strings — test field length limits39- Copy-paste — paste rich text, formatted content, URLs4041**State heuristics:**42- Interruptions — navigate away mid-action, close browser, lose connection43- Concurrency — same action from two tabs/devices simultaneously44- Sequence — perform actions in unexpected order45- Speed — rapid repeated actions (double-click, fast submit)46- Stale state — leave page open for extended time, then act4748**Environment heuristics:**49- Different browsers, devices, screen sizes50- Slow network, offline, high latency51- Low disk/memory conditions52- Different locales, time zones, languages5354**Data heuristics:**55- Fresh vs. existing data56- Large datasets vs. empty state57- Data with special relationships (self-referencing, circular)58- Permissions boundaries (own data vs. others' data)5960### Step 4: Session Notes Template6162For each exploration session, record:6364```65Charter: [what you explored]66Duration: [time spent]67Environment: [where you tested]6869Findings:70- [Bug/Observation] Description (Severity: High/Med/Low)71- [Bug/Observation] Description (Severity: High/Med/Low)7273Areas not covered:74- [what you didn't get to explore]7576Questions:77- [things to clarify with the team]78```7980## Output Format81821. Test charters table832. Applicable heuristics for this feature843. Session notes template854. Risk areas to focus on865. Suggested test data and environments8788## Edge Cases8990- For new features: focus on requirement gaps and assumption testing91- For bug fixes: explore around the fix — similar inputs, related flows92- For performance: explore under load, large data, concurrent users93- For mobile: focus on gestures, orientation, interruptions (calls, notifications)9495## Quality Checklist9697- [ ] Output is specific and actionable, not generic98- [ ] All relevant inputs have been gathered before producing output99- [ ] Recommendations are prioritized by impact100- [ ] Stakeholders and audience are identified101- [ ] Output format matches the audience's needs102- [ ] Key assumptions are documented103- [ ] Follow-up actions have clear owners
ashutoshsrivastava17