菜单
SBTM-style exploratory testing session — charter-driven, tour-guided, time-boxed human investigation
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Create or complete a CorgiSpec planning package and synchronize one GitHub parent issue plus Task Group child issues. Use when proposing a change whose normalized tracking provider is GitHub.
Create or complete a CorgiSpec planning package and optionally synchronize GitLab issues. Use when proposing a new change or finishing an existing change whose normalized tracking provider is GitLab or none.
Execute or resume a CorgiSpec Run Contract v2 one Task Group at a time through the canonical corgispec loop CLI. Use when starting, continuing, fixing, committing, recovering, or finalizing an implementation run; never write loop state or evidence artifacts directly.
Implement exactly one pending Task Group from a CorgiSpec change and optionally synchronize GitLab progress. Use when applying a change whose normalized tracking provider is GitLab or none.
Validate and archive a completed CorgiSpec change, extract durable knowledge, and optionally close GitLab tracking. Use when archiving a change whose normalized tracking provider is GitLab or none.
Compare fresh CorgiSpec planning, implementation, Git, and run evidence and close only implementation gaps through the canonical converge CLI. Use after implementation or review when deciding whether a change is converged, planning needs update, or a new append-only Task Group is required.
| name | corgispec-qa-exploratory |
| description | SBTM-style exploratory testing session — charter-driven, tour-guided, time-boxed human investigation |
| license | MIT |
| compatibility | Universal. Works with any codebase or platform. |
| metadata | {"author":"corgispec","version":"1.0.0","generatedBy":"1.0.0"} |
Session-Based Test Management (SBTM), developed by James Bach and Michael Bolton, structures exploratory testing into accountable, time-boxed sessions. Each session has a charter (mission), uses one or more Test Tours to guide exploration, and produces a debrief report with findings and coverage notes.
Exploratory testing is simultaneous learning, test design, and test execution. It is not ad-hoc — it is disciplined investigation guided by heuristics and documented in real time.
| Phase | Duration | Activity |
|---|---|---|
| Charter | 5 min | Define mission, scope, and success criteria |
| Explore | 30–55 min | Systematic investigation using selected tours |
| Note | Continuous | Record observations, findings, questions as they occur |
| Debrief | 10–15 min | Summarize coverage, findings, and next steps |
Select 2–4 tours per session based on the change context.
| # | Tour | Description | When to Recommend |
|---|---|---|---|
| 1 | Business District | Exercise key business flows end-to-end | All changes — validates core value paths |
| 2 | Money | Probe revenue-related features (payments, subscriptions, pricing) | Payment/billing changes |
| 3 | Bad Neighborhood | Focus on historically buggy areas | Historically buggy modules |
| 4 | Historical | Revisit past bug clusters and regressions | Legacy code changes |
| 5 | FedEx | Track data as it flows through the entire system | Full-stack or integration changes |
| 6 | Rained-Out | Explore failure modes, error handling, edge cases | All changes — validates resilience |
| 7 | Obsessive-Compulsive | Repeat operations rapidly, vary sequences | Loops, batch processing, concurrency |
| 8 | Garbage Collector | Test cleanup, boundaries, limits, resource exhaustion | CRUD operations, resource management |
| 9 | Intellectual | Challenge complex logic with tricky inputs and edge cases | Algorithms, business rules, calculations |
| 10 | Couch Potato | Take the minimal effort path, use defaults only | UX flows, onboarding, happy paths |
| 11 | Landmark | Navigate via key features and integration points | New features, UI navigation |
| 12 | Museum | Examine help docs, examples, error messages, tooltips | SDK, library, or API documentation |
If called from a molecule (e.g., corgispec-qa-session), read the charter provided. Otherwise, define your own charter:
Choose 2 to 4 tours from the table above based on the change context. Different scenarios call for different Tour strategies:
For each selected tour:
Classify each finding:
| Severity | Definition |
|---|---|
| Blocker | Prevents core functionality, no workaround |
| Critical | Major feature broken, workaround exists but unacceptable |
| Major | Significant issue affecting user experience |
| Minor | Small defect, cosmetic, or low-impact behavioral issue |
| Trivial | Nitpick, suggestion, or style concern |
Compile the session report (see Reporting format below).
If the change directory contains qa-testcases.md, read it before starting exploration. Use the documented test cases as a baseline — your exploratory session extends beyond them, finding what structured cases miss.
## Exploratory Test Session Report
- **Session ID**: ET-{YYYY-MM-DD}-{NNN}
- **Charter**: {mission statement}
- **Duration**: {actual minutes} / {planned minutes}
- **Tours Used**: {list of tours selected}
### Coverage
{Areas explored, features touched, paths taken}
### Findings
| # | Severity | Tour | Finding | Evidence |
|---|----------|------|---------|----------|
| 1 | major | FedEx | Data lost between step X and Y | screenshot/log ref |
### Oddities
{Things that aren't bugs but seem wrong, surprising, or worth investigating later}
### Debrief
- **Coverage confidence**: {low/medium/high} — {why}
- **Areas not reached**: {what was skipped and why}
- **Recommendations**: {follow-up sessions, automated tests to add, areas needing deeper review}
### Evidence
{Links to screenshots, logs, recordings, or reproduction steps}