exploratory-test-charter
GitHub生成基于会话的探索性测试章程，聚焦高风险区域。提供明确任务、测试策略和判定标准，确保测试目的性强且可追溯，避免盲目操作。
Trigger Scenarios
Install
npx skills add mohitagw15856/pm-claude-skills --skill exploratory-test-charter -g -y
SKILL.md
Frontmatter
{
"name": "exploratory-test-charter",
"homepage": "https:\/\/mohitagw15856.github.io\/pm-claude-skills\/skill\/exploratory-test-charter.html",
"metadata": {
"openclaw": {
"emoji": "🧪"
}
},
"description": "Write session-based exploratory testing charters to find what scripted tests miss. Use when asked to plan exploratory testing, write a test charter, design a testing session, or do risk-based exploration of a feature. Produces focused charters — a mission, areas\/risks to explore, tactics and oracles, and timeboxed sessions — so exploration is purposeful and accountable, not random clicking."
}
Exploratory Test Charter Skill
Exploratory testing finds the bugs scripts don't — but only when it's chartered: a clear mission, a defined area, and a timebox, so it's purposeful and you can report what was covered. This skill writes session-based charters that point skilled testing at the riskiest areas, with the tactics and oracles to know when something is wrong.
Working from a brief
Given "explore the new checkout flow", write the charters anyway — infer the risk areas, useful tactics, and oracles, labelling assumptions. Prioritise by risk. Never hand back a question instead of charters.
Required Inputs
Ask for these only if they aren't already provided (else infer and label):
- The target — the feature/area and what it does.
- Risk & concerns — what's new/changed, what's complex, and where failure would hurt most.
- Context — users, platforms, data, and integrations involved.
- Time available — to size and prioritise the sessions.
Output Format
Exploratory Testing Charters: [feature]
Risk overview — the few areas most worth exploring and why (new, complex, high-impact, historically buggy).
Charters — one per focused session (Session-Based Test Management style):
Charter: Explore [area] using [tactics/data] to discover [information about risk].
- Areas / things to cover: the specific surfaces, flows, inputs, states.
- Test ideas & tactics: how to probe it — boundary values, interruptions, bad data, concurrency, navigation, roles/permissions, network conditions, etc.
- Oracles (how you'll know it's wrong): the spec, consistency, comparable products, user expectations, "would a user be annoyed?".
- Timebox: ~60–90 min (short/long), priority.
- Data / setup needed.
Provide 3–6 charters, prioritised by risk.
Reporting — what to capture per session: bugs found, areas covered vs. not, new risks/questions, and follow-up charters.
Quality Checks
- Each charter has a clear mission (explore X to discover Y about risk Z) — not "test the app"
- Charters are prioritised by risk, with the rationale stated
- Test ideas/tactics are concrete (boundaries, interruptions, bad data, roles…), not generic
- Oracles are named so the tester can recognise a problem
- Sessions are timeboxed and sized to the available time
- A lightweight reporting structure (coverage + findings) is included
Anti-Patterns
- Do not write "explore the feature" with no mission, areas, or oracles — that's aimless clicking
- Do not skip prioritisation — explore the riskiest areas first
- Do not turn charters into scripted step-by-step cases — exploration needs freedom within focus
- Do not omit oracles — without them a tester can't tell right from wrong
- Do not leave sessions open-ended — timebox them so coverage is accountable
Based On
Session-Based Test Management (exploratory testing) — chartered, risk-prioritised, timeboxed sessions with explicit tactics and oracles.
Version History
- 54fad50 Current 2026-07-19 12:19
