bug-bash-facilitator
Builds a structured bug-bash session - pre-bash kit (charter, test-data prep, environment setup, sign-up sheet), in-bash structure (role rotation across cohorts, shared backlog board, real-time triage), scoring rubric (severity weighting, novelty bonus), and a post-bash same-day wrap-up authored by the facilitator (not a standalone debrief: for post-session writeups without a live bash, use manual-test-debrief). Use when a team needs a coordinated multi-tester sweep before a release or after a major change - converts an ad-hoc "everyone test for an hour" into a recorded, comparable session with deliverables.
Install with skills.sh (any agent)
npx skills add testland/qa --skill bug-bash-facilitatorbug-bash-facilitator
Overview
An unfacilitated bug bash is "everyone clicks around for an hour and we hope something turns up." The result: lots of duplicates, no triage, debrief skipped, no record.
A facilitated bug bash is a structured exploratory session at team scale - multiple testers in coordinated cohorts, shared backlog visible to all, triage in real-time, debrief that produces follow-ups.
This skill builds the kit + structure + scoring + debrief.
When to use
If the goal is a single tester running a charter, author a single exploratory charter directly. Bug bashes are the multi-tester / scaled version.
Step 1 - Pre-bash kit (1 week before)
# Bug bash - `<release / feature / area>`
**Date:** YYYY-MM-DD
**Time:** 14:00-15:30 (90 min)
**Environment:** staging.example.com (build `v1.4.5-rc1`)
**Facilitator:** _______________
**Note-taker:** _______________
## Mission
Find regressions, edge cases, and usability issues in the new
checkout flow before the release on YYYY-MM-DD.
## Charters (5 cohorts × 90 min)
Per cohort, 1-2 testers + 1 facilitator-roving:
- **Cohort A - Money:** Apply the Money tour
across the new checkout discount + tax flow - visit every place
money / pricing / currency / discount appears and verify each;
hunts rounding errors, currency-conversion drift, discount
stacking, free-shipping edges, locale formatting (€1.234,56 vs
$1,234.56).
- **Cohort B - Bad data:** Apply the Bad-data tour
across promo code input, address fields, payment fields - feed
pathological inputs (empty, single space, 5000 chars, SQL
injection, XSS, unicode bidi override, RTL text, emoji ZWJ
sequences, null byte) and observe validation + error handling.
- **Cohort C - Configuration:** Vary user state (new vs existing
account, EU vs US user, mobile vs desktop) and re-run hero flows.
- **Cohort D - Landmark:** Walk the canonical hero flow (search →
add to cart → checkout → confirmation) under various conditions.
- **Cohort E - Garbage collector:** Visit every page in the
checkout funnel; flag 404s, broken images, stale strings.
## Test data prep (do BEFORE the bash)
- [ ] Create 5 test accounts with varying states (per
`synthetic-data-tool-selector`):
`qa-bash-A`, `qa-bash-B`, ..., `qa-bash-E`.
- [ ] Seed promo codes: `WELCOME10`, `EXPIRED50`, `MIN100`,
`STACKABLE5`.
- [ ] Pre-fund the Stripe test account; expose test cards
(Stripe test card list).
- [ ] Verify staging is at the right SHA; tag artifact.
## Sign-up sheet
| Cohort | Tester(s) | Notes |
|--------|-------------------|-------|
| A | | |
| B | | |
| ... | | |The kit is sent 1 week before so testers can prepare and team members can RSVP. Testers who can't attend live get an async-charter version.
Step 2 - In-bash structure
14:00-14:05 Kickoff (facilitator presents the mission, charters, scoring rubric)
14:05-14:50 Round 1 (each cohort runs its charter; ~45 min)
14:50-15:00 Mid-bash huddle (5-min check-in: what's everyone seeing?)
15:00-15:25 Round 2 (cohorts swap charters; new lens on the same area)
15:25-15:30 Wrap (everyone logs final bugs; facilitator closes the board)The cohort swap at the midpoint is critical - it's the same testers looking at the area through a fresh lens, and it surfaces bugs that the first cohort's tour missed.
Step 3 - Shared backlog board
A shared spreadsheet / Notion table / GitHub issues view that everyone can see live during the bash:
| ID | Time | Cohort | Reporter | Title | Severity | Repro | Triage | Owner | Final disposition |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 14:08 | A | Alice | Promo WELCOME10 not applied | high | Cart BOOK-001; apply code | bug | Bob | BUG-987 |
| 2 | 14:12 | B | Bob | Promo input accepts SQL injection | high | Type '; DROP-- and apply | bug | Bob | BUG-988 |
| 3 | 14:15 | A | Alice | Subtotal off by 1 cent on $24.99 + 10% | low | Apply WELCOME10 to $24.99 | bug | Carol | BUG-989 |
| 4 | 14:20 | C | Carol | EU user sees $ symbol instead of € | medium | Set locale=EU; checkout | bug | Dave | BUG-990 |
The Triage column is filled in real-time by a roving facilitator who decides:
Real-time triage prevents the debrief from being a giant classification exercise.
Step 4 - Scoring rubric
Optional but motivating: a points system.
| Finding type | Points |
|---|---|
| Critical (data loss, P0) | 10 |
| High (broken flow) | 5 |
| Medium (degraded UX) | 3 |
| Low (cosmetic / minor) | 1 |
| Novel (no one else thought to check) | +2 bonus |
| Cluster lead (the first row in a 3+-row cluster) | +1 bonus |
| Duplicate (already on board) | 0 |
Tally per cohort + per individual at the wrap. The points are explicitly fun, not performance review - but they motivate testers to go beyond the obvious.
Step 5 - Post-bash debrief
Within 24 hours, the facilitator + note-taker produce:
## Bug bash debrief - `<release>`
**Date:** YYYY-MM-DD
**Participants:** N (across 5 cohorts)
**Duration:** 90 min
### Findings summary
| Severity | Count | Notes |
|------------|------:|-------|
| Critical | 0 | |
| High | 6 | 4 cluster (promo flow); 2 isolated (config) |
| Medium | 14 | |
| Low | 23 | mostly cosmetic / copy issues |
| **Total** | 43 | |
### Cluster analysis
| Cluster | Bugs | Bug IDs | Owner | Action |
|------------------------|-----:|------------------------|----------|--------|
| Promo apply edge cases | 7 | BUG-987, 988, 989, 990, 991, 992, 993 | Bob | Block release until fixed. |
| EU locale bugs | 3 | BUG-994, 995, 996 | Dave | Fix in current sprint. |
| Cosmetic / copy | 12 | (per-bug) | Eve | Backlog; address over the next 2 sprints. |
### Cohort scoring (per Step 4)
| Cohort | Findings | Points | Top finder |
|--------|---------:|-------:|------------|
| A | 12 | 34 | Alice (BUG-987 high + 2 cluster lead bonuses) |
| B | 9 | 27 | Bob (SQL injection - high + novelty) |
| ... | | | |
### Process retrospective
What went well: ...
What didn't: ...
What to change for next bash: ...
### Action items
- [ ] Bob: fix BUG-987 cluster within 48h (release blocker).
- [ ] Dave: fix EU locale cluster in current sprint.
- [ ] Eve: backlog the 12 cosmetic items for grooming.
- [ ] Facilitator: schedule next bash for `v1.5.0` release.Step 6 - Async participants
Team members who can't attend live get a mini-charter to run solo within the same week:
# Async bug bash mini-charter - `<release>` (cohort: pick one)
You missed the live bash; here's the 30-min version. Pick a
cohort that wasn't done yet (or revisit one with a new lens).
(charter cohort body)
When done, log findings to the same shared board with
`async` tag.Async participation isn't ideal (no roving facilitator, no live triage) but it broadens coverage.
Anti-patterns
| Anti-pattern | Why it fails | Fix |
|---|---|---|
| Open-ended "everyone test for an hour" | Heavy duplication; no coverage map; debrief skipped. | Cohorts + charters (Step 1). |
| No real-time triage | Debrief becomes a 3-hour classification exercise. | Roving facilitator triages live (Step 3). |
| Scoring as performance review | Testers chase points, miss high-value bugs. | Scoring is for fun + motivation; explicit "not performance" disclaimer. |
| Bug bash without test-data prep | Testers spend half the time creating accounts. | Pre-prep test data 1 week ahead (Step 1). |
| Same-cohort assignments quarter after quarter | Same testers find the same bugs. | Rotate assignments; mid-bash cohort swap (Step 2). |
| Post-bash with no follow-up actions | Bugs sit in the backlog; team disillusioned by next bash. | Action items per cluster owner (Step 5). |
| Running the bash on a stale build | Bugs found are already-fixed; testers waste time. | Tag the build SHA; verify staging is current. |
Limitations
References
Related skills
crusspic-stmpl-heuristic
Pure-reference catalog of James Bach's CRUSSPIC STMPL heuristic - thirteen quality criteria (quality attributes / non-functional requirements) a tester can evaluate a system against. CRUSSPIC: Capability, Reliability, Usability, Security, Scalability, Performance, Installability, Compatibility. STMPL: Supportability, Testability, Maintainability, Portability, Localizability. Use when checking a product's quality attributes or non-functional requirements, or picking which quality characteristics a test session evaluates - a checklist for judging product quality holistically; complementary to the ISO/IEC 25010 software product-quality model.
decision-table-test-design
Derives human-readable manual test cases from a business-rule spec via a decision table: identify conditions and actions, build the full 2^n-column matrix, collapse columns with irrelevant entries, strike infeasible combinations, then emit one test case per remaining column (each feasible column is one coverage item per ISTQB CTFL v4.0 section 4.2.3). A deep single-technique walkthrough rather than a broad multi-lens case matrix; the output is manual step/expected cases rather than parameterized test code, and it covers how cases are derived rather than how a case record is structured. Use when a spec's outcome depends on interacting conditions (pricing, eligibility, discounts, routing rules) rather than the boundaries of a single input.
exploratory-tours-reference
Pure-reference catalog of the seven exploratory testing tours from Whittaker's Exploratory Software Testing (2009): Feature, Money, Landmark, Intellectual, Bad-data, Configuration, and Garbage-collector's, each a themed mission with the signal it surfaces and a worked example. Use as the menu a charter author picks session themes from. Distinct from the mnemonic catalogs sfdpot-exploratory-heuristic (what to vary) and hiccupps-f-heuristic (oracles), and from session-based-test-management-reference, which manages the sessions.
fcc-cuts-vids-heuristic
Pure-reference catalog of Michael Kelly's FCC CUTS VIDS touring heuristic (2005): eleven tours - Feature, Complexity, Claims, Configuration, User, Testability, Scenario, Variability, Interoperability, Data, Structure - each a reconnaissance sweep that builds familiarity with an unfamiliar application. Use when onboarding onto a product or opening a first session on an unknown area, before a charter is scoped. Distinct from exploratory-tours-reference (Whittaker's seven tours, which frame a bug-hunting mission on a product the tester already knows), sfdpot-exploratory-heuristic (what to vary), hiccupps-f-heuristic (oracles), and crusspic-stmpl-heuristic (quality criteria).
hiccupps-f-heuristic
Pure-reference catalog of Michael Bolton's HICCUPPS-F oracle heuristic - the reference points a tester consults to decide 'is this a bug?': History, Image, Comparable products, Claims, Users' desires, Product (internal consistency), Purpose, Standards/statutes, plus Familiar problems. Use mid-session to test an observation against each oracle. For what to VARY use sfdpot-exploratory-heuristic, for touring an unfamiliar product use fcc-cuts-vids-heuristic, for quality criteria use crusspic-stmpl-heuristic.
manual-test-debrief
Session debrief template + tour-coverage tracker - captures the SBTM PROOF format (Past, Results, Obstacles, Outlook, Feelings) plus three-bucket time accounting (test design / setup / bug investigation), the tours applied + areas covered + areas skipped, and the per-session quality-of-attention signal. Output is the artifact a charter delivers into; the team aggregates debriefs across sessions to track what's been explored vs what's still uncharted. Use after every exploratory session - without the debrief, the session's findings disappear.
manual-test-script-author
Builds stakeholder-readable scripted manual test cases from a feature spec - emits either a step-table format (preconditions / steps / expected result / actual / pass-fail / notes) for spreadsheet review or a Gherkin Given/When/Then format for BDD-aware teams. Each script is self-contained (no implicit team knowledge), single-scenario (one happy + N edge per script), and includes the data setup the tester needs without being a developer. Use when a feature can't be (or shouldn't be) fully automated and a human tester needs an executable script - UAT, regression baselines, certification testing, exploratory follow-up scripts.
manual-testing-overview
Teaches human-driven testing end to end: when a predefined scripted test case is the right instrument versus a time-boxed exploratory session, how session-based test management works (charter with a stated mission, time box, session notes, debrief) with a worked charter and a filled-in session sheet, a decision rule for what to automate versus what to keep human, and what makes a manual bug report actionable (exact reproduction steps, observed versus expected, build and environment, evidence). Use when planning or running testing a person performs by hand, writing a charter for an exploratory session, deciding whether a check belongs in an automated suite or in a human session, or fixing bug reports that developers keep returning as not reproducible.
session-based-test-management-reference
Pure-reference catalog of Session-Based Test Management (SBTM) - the Bachs' framework for running exploratory testing as time-boxed sessions: the session (60-90 min), the charter (Explore X with Y to discover Z), the session-sheet structure, the TBS metrics, the cross-session dashboard, and the PROOF debrief. Use when authoring exploratory-testing charters, reviewing session sheets, or setting up time-boxed test sessions. Distinct from manual-test-debrief (the PROOF debrief template), exploratory-tours-reference (the session themes), and the heuristic catalog hiccupps-f-heuristic.
sfdpot-exploratory-heuristic
Pure-reference catalog of James Bach's SFDPOT heuristic - 'San Francisco Depot' - a 'you are here' framework that catalogues what a tester can vary in a system to find bugs. Six dimensions: Structure, Function, Data, Platform, Operations, Time. Use as a what-to-vary checklist during an exploratory session, complementing HICCUPPS-F (which catalogues what to compare against).
state-transition-test-design
Derives human-readable manual test cases from stateful behavior: identify states, events, transitions, and guard conditions, draw the state table including invalid (empty-cell) transitions, choose a coverage level (all states, valid transitions / 0-switch, transition pairs / 1-switch per Chow, all transitions including invalid ones), then derive one test case per coverage item as an event sequence with per-step expected states (ISTQB CTFL v4.0 section 4.2.4). A deep single-technique walkthrough rather than a broad multi-lens case matrix; the output is manual step/expected cases rather than parameterized test code, and it covers how cases are derived rather than how a case record is structured. Use for lifecycle entities (accounts, orders, subscriptions), workflows, and UI wizards where the response to an event depends on the current state.
test-execution-checklist
Converts a regression suite (or test plan) into an executable manual checklist for cases when automation isn't viable - a release-day smoke checklist, a post-incident verification list, or a periodic compliance check. Outputs a per-TC checkbox list with the minimal preconditions, the action, and a one-line "what to look for" - short enough to fit on one page per major flow. Use when the team needs a focused human-runnable list (not full step-tables), e.g., for production smoke after deploy or for the on-call rotation's quick verification.
uat-script-author
Emits User Acceptance Testing scripts in stakeholder-readable format - pre-conditions / business-language steps / expected business outcome / pass-fail / sign-off. Tailored for non-developer testers (end users, SMEs, solution owners) per the UAT canonical definition. Output is one TC per stakeholder-meaningful scenario with explicit sign-off, suitable for compliance / contract / audit records. Use when a release requires formal UAT before sign-off - typical for B2B contracts, regulated industries, or any delivery where the customer's acceptance is the contractual gate.