Qa Sbtm

---
name: qa-sbtm
description: "[QA Method] Session-based exploratory testing: SBTM charters, heuristics (CRISP/SFDPOT), tours, session notes, debrief."
argument-hint: "domain | charter type | heuristic"
---

# /qa-sbtm — Session-Based Test Management (SBTM) Methodology

Provides the structured methodology framework for exploratory testing sessions. This skill defines HOW to explore — charters, heuristics, tours, note-taking, and debriefs. Use it as a reference before and during exploratory sessions.

**Relationship to `/qa-exploratory` command:** The `/qa-exploratory` command dispatches and manages exploratory sessions. This skill (`/qa-sbtm`) provides the methodology reference that agents read during those sessions.

## Usage
```
/qa-sbtm                   # Full methodology overview
/qa-sbtm charter           # Charter creation guide + templates
/qa-sbtm CRISP             # CRISP heuristic reference
/qa-sbtm SFDPOT            # SFDPOT heuristic reference
/qa-sbtm tours             # Exploration tour patterns (basic + Whittaker)
/qa-sbtm debrief           # Debrief process and templates
/qa-sbtm discovery         # Scenario discovery — techniques for finding scenarios we don't cover (PRIMARY purpose of exploratory)
/qa-sbtm adversarial       # Adversarial heuristics — Whittaker tours, FAILURE, Soap Opera, HICCUPPS-F (use as filters, not checklists)
/qa-sbtm personas          # Persona-driven exploration (Impatient Buyer, Screen-Reader User, Malicious User, etc.)
/qa-sbtm attack-surface    # Modern web attack surface — DevTools, multi-tab, cache, history, browser features
/qa-sbtm charters          # Ready-to-use charter library (11 charters) — starting points to be galumphed/hostile-interviewed
/qa-sbtm sprint            # Sprint-charter selection — which domains of a sprint plan earn a 30-min charter
```

## Supporting Files

- **scenario-discovery.md** — **PRIMARY lens for exploratory sessions.** 10 techniques for finding scenarios our coverage misses: coverage-diff hunting (suite vs codebase / spec / prod logs / JIRA), feature-pair matrix, user-flow edge enumeration, surprise-seeking time, boundary-of-features hunting, galumphing, hostile interview, production-error mining, charter-from-gap protocol, debrief net-new-scenario rule. Every session must end with at least one net-new scenario or be logged as re-validation, not exploration.
- **session-based-testing.md** — Core SBTM framework: charter creation, CRISP/SFDPOT heuristics, basic exploration tours, session notes template, debrief process, coverage tracking, learning loops
- **adversarial-heuristics.md** — Heuristics for breaking the app: Whittaker's 10 tours (Garbage Collector, Bad Neighborhood, Couch Potato, Antagonistic, Saboteur, Obsessive-Compulsive, Supermodel, Lonely Businessman, All-Nighter, Tourist), FAILURE mnemonic, Soap Opera Testing template + 2 VC examples, HICCUPPS-F oracles, combination guide
- **personas.md** — Persona-driven exploration: 6 personas (Impatient Buyer, Screen-Reader User, Malicious User, Slow-Network User, B2B Procurement Officer, Session-Corrupted User) with mindset, test ideas, what they typically find, and recommended heuristic pairings
- **modern-web-attack-surface.md** — Browser-specific probes: DevTools-as-attack-tool, multi-tab state collisions, storage/cache drift (incl. ServiceWorker), history/router races, browser-feature attack surface (autofill, dark mode, zoom, print, reduced-motion), network-layer probes, performance/memory probes. Each probe linked to Chrome DevTools MCP or Playwright MCP execution
- **sprint-charter-selection.md** — **The scheduling rule.** Given a written sprint test plan, derives which §3 risk domains earn a charter (C1 uncovered surface / C2 concurrency seam / C3 cross-layer chain / C4 latent blast radius), which are disqualified as plain test cases (D1 exact oracle / D2 no QA surface / D3 already charted), the 5-charter budget, the non-firefox lane rule, and the capture-back contract that turns a net-new scenario into a permanent `Draft` case. Consumed by `/qa-test-plan` §5.3 and `/qa-exploratory sprint`.
- **charter-library.md** — 11 ready-to-use charters, each declaring the `ECL-<n>.<m>` sections it hunts (§Edge-Case Refs — they were uncited restatements of the library until then): Checkout Edge Cases, B2B Procurement, Admin Resilience, API Edge Cases, Feature Flag Lifecycle, Performance & Resource Stress, Accessibility Exploratory, i18n/Localization, Mobile Gesture-Specific, Search Relevance, Cache & State Drift

## Execution

1. **Read the methodology references:** Load `scenario-discovery.md` FIRST — it defines the primary lens (finding scenarios we don't cover). Then `session-based-testing.md` for the core SBTM framework. Consult `../../agents/knowledge/oracles/vc-bug-catalog.md` BEFORE the session to learn what NOT to re-discover, and the two SUPPLY-side oracles — `e-commerce-edge-cases-library.md` for candidate boundary/failure shapes (**`[THEORETICAL]` sections first**: `[OBSERVED]` ones are already `/qa-checklist`'s and the suites' job) and `bl:extract` for the `BL-*` a deviation is judged against. The three are read in two opposite directions — the catalog and the suites to SUBTRACT known ground, the ECL and BL to SUPPLY targets and a correctness reference; the table is at `/qa-exploratory` Step 5a. For Risk and Edge-Case charters, also load `adversarial-heuristics.md` (apply as filters / familiar-problems oracle, not as a checklist). Pick a persona from `personas.md` when the session benefits from a specific user lens. Reach for `modern-web-attack-surface.md` when probing cache, multi-tab, or browser-feature surfaces.

2. **Before a session — Charter creation:**
   - Define the mission (what area to explore and why)
   - Select charter type: Feature, Risk, Workflow, or Edge-Case
   - Choose applicable heuristic(s): CRISP for quality attributes, SFDPOT for system dimensions
   - Set time box: 30-minute session (5 min setup + 20 min explore + 5 min document)
   - **Ask the base about the charter area** — `mcp__kb__kb_ask` (CLI: `npm run kb -- ask "<coordinate> <question>"`), one question per page path / GraphQL operation in the charter. What it already holds is known ground to subtract, exactly like the bug catalog

3. **During a session — Guided exploration:**
   - Follow the selected heuristic's sub-questions to guide exploration
   - Apply tour patterns (Feature, Complexity, Claims, Scenario, Data) for systematic coverage
   - Log findings in real-time using the session notes template
   - Classify findings: Bug, Question, Observation, Risk

4. **After a session — Debrief:**
   - Review findings: how many bugs, questions, observations, risks
   - Assess coverage: what percentage of the charter was covered
   - Identify follow-up actions: bugs to file, questions to answer, risks to escalate
   - Update the coverage tracking matrix (area x session)
   - **Bank every Observation that is platform behaviour**: matched ⇒ `kb confirm <id>`, contradicted ⇒ `kb dispute <id>`, unrecorded ⇒ `kb capture` (`--deployment <env>`, nothing client-specific) — an exploratory session is where the base gets most of its new entries ([`authoring-standard.md`](../../knowledge/agents/authoring-standard.md) §5)

5. **Learning loops — Continuous improvement:**
   - Bug found → update risk register (see `/qa-risk`)
   - Risk identified → create new charter targeting that risk
   - Coverage gap found → schedule follow-up session
   - Pattern observed → add to error guessing heuristics (see `/qa-test-design`)

## Integration with Other Skills
- `/qa-test-plan` §5.3 is the scheduler — it derives a sprint's charters via `sprint-charter-selection.md`; `/qa-exploratory sprint` runs them
- `/qa-risk` determines which areas need exploratory attention (High/Critical risk items)
- `/qa-test-design` provides error guessing heuristics that supplement exploration
- `/qa-evidence` defines how to capture and format session evidence
- `/qa-investigate` provides the investigation flow when a bug is found during exploration
- `/qa-coverage-gap` provides programmatic coverage analysis complementary to manual scenario discovery
- Findings feed into `/qa-metrics` (defect density, escape rate)

## Test Data
Discovery sessions hit live data that drifts. Resolve at runtime via the decision tree in [`../../../agents/knowledge/execution/live-discovery.md`](../../knowledge/execution/live-discovery.md): `live-discover` for any-entity navigation, `random-data` for unique throwaway inputs, `@td(ALIAS.field)` for specific assertion targets. Never hardcode GUIDs/SKUs/prices encountered during a session — when a discovered gap becomes a follow-up test case, the new case must use this decision tree.

## Rules
- **Discovery first**: every exploratory session must end with at least one net-new scenario (not covered by any CSV suite or the VC bug catalog). If it doesn't, log it as `[VAL]` re-validation, not `[EXP]` exploration (see `scenario-discovery.md` § 10).
- Every exploratory session must have a written charter — no aimless clicking (except for the 10-min surprise-seeking time at the start, which IS the discipline)
- Time-box is mandatory: 30 minutes per session, extendable to 45 min max
- Log findings in real-time, not from memory after the session
- Debrief is not optional — every session ends with a findings review AND a net-new-scenario answer
- Coverage tracking matrix must be updated after each session, with `[EXP]/[VAL]` marker
- At least 2 exploratory sessions required before any full release (per quality-gates.md)
- **A sprint charter is scheduled, not improvised**: the charter set is derived from the plan's own §3 / §5.2 per `sprint-charter-selection.md` — never a domain absent from §3, never a suite absent from §5.1
- **Every net-new scenario has a recorded fate** — promoted to a `Draft` case, or declined with a one-line reason (`sprint-charter-selection.md` §6). An unexplained absence means the finding was discovered once and lost