How to run a bug bash

A bug bash session is the event: a scheduled hunt on one build, not a standing QA meeting. This playbook is the process — plan, kickoff, hunt, log, triage, recap — with a timetable and checklists. If you still need the definition, start with what a bug bash is.

What you are running

You are running a time-boxed, cross-functional exploratory session on a named build. Success is a triaged list of bugs with owners — not a high message count in Slack, and not a pile of unwatched recordings.

Keep the invite small enough to moderate (8–20 people is a common range) and diverse enough to cover roles: at least QA, one engineer who did not own the feature, design or product, and someone who talks to customers. Give testers charters, not a script.

Block two hours on the calendar even if the hunt is 90 minutes. Kickoff and recap need a home. If people can only stay for the hunt, still schedule triage the same day so findings do not rot.

Suggested timetable

Use this as the default and cut it only if the scope is tiny (a single screen).

Kickoff: 10 minutes. Build URL, out of scope, known issues, where to file, charter assignments. Do not take feature requests here.

Hunt: 60–90 minutes. People explore and log. Moderator unblocks access. No mid-hunt all-hands discussion of roadmap.

Debrief / recap: 15 minutes. Top findings, launch-blocking vs later, duplicates to merge, thanks, and when triage will close.

Triage can overlap the recap for a small pile, or follow as a 30-minute working session with the triage owner plus one engineer. Do not skip it. A bash without triage is a recording of a bash.

Before the bash

Do this the day before, not in the kickoff. An unstable environment will consume the hunt.

• Name the build (version, URL, feature flags) and freeze it for the session if you can.
• Write 5–12 charters: areas or questions, not step-by-step cases.
• Publish a known-issues list and out-of-scope list.
• Seed test accounts and data (empty, full, admin, restricted, long names, unpaid invoices — whatever you actually have in production).
• Pick one log (Jira project/label, spreadsheet, or session tool). Ban Slack as the tracker.
• Name a moderator, a stager, and a triage owner.
• Send access instructions: VPN, SSO, passwords, which browser if it matters.
• Tell people how to capture evidence (screenshot vs short clip vs full session recording).

During the hunt

Kickoff is short on purpose. Then the room should go quiet except for environment problems.

• Restate scope, known issues, and the log. Assign charters so login is not everyone’s first hour.
• Demo the happy path once if the product is unfamiliar.
• Start the timer. Moderator watches the clock and the stager watches the env.
• Log as you go: steps, expected vs actual, evidence. Do not batch “I’ll write tickets later.”
• If two people collide on the same bug, link rather than re-describing.
• Stop feature debate. File a bug or a “question” ticket; design it later.
• Leave ten minutes before recap so people can finish the ticket they are mid-writing.

After: triage and recap

The event is not finished when the hunt ends. Close the loop the same day if you can.

• Deduplicate. Merge or link copies before anyone starts fixing.
• Set severity and launch-blocking vs later. Product or QA lead, not whoever typed fastest.
• Assign owners or a next queue (sprint, parking lot). Unowned tickets will not ship.
• Recap: counts, the few bugs that matter, what you did not cover, what to change next bash.
• Update the known-issues list from what you learned.
• Thank testers. People return when they see their bugs get owners.

The bug bash process, step by step

1. 1. Plan the bash Pick the build, time box, and scope. Write charters and a known-issues list. Choose one place to log bugs. Name a moderator, stager, and triage owner. Seed accounts and data.
2. 2. Kickoff (10 minutes) Share the build URL, out-of-scope list, known issues, and filing instructions. Assign charters. Demo the happy path once. Do not turn kickoff into a product review.
3. 3. Hunt (60–90 minutes) Testers explore their charters, then wander. The moderator unblocks access and protects the clock. The stager keeps the environment alive.
4. 4. Log as you go Each finding gets steps, expected vs actual, and a screenshot or clip (with a timestamp if the evidence is a longer recording). Chat is for environment issues, not the backlog.
5. 5. Triage The triage owner duplicates, sets severity, and assigns. This can start in the recap for a small pile; it must finish before you call the bash done.
6. 6. Recap (15 minutes) Share what you found, what is launch-blocking, and what you skipped. Thank the room. Note one process change for next time.

If findings are trapped in recordings, use a bug bash session tool

FAQ

How to run a bug bash?

Plan the build and charters, kick off for 10 minutes, hunt for 60–90 minutes while logging bugs with expected vs actual and evidence, then triage and recap for about 15 minutes. Use one tracker — not Slack — and name a moderator, stager, and triage owner.

What is the bug bash process?

The bug bash process is plan → kickoff → hunt → log → triage → recap. The hunt is the long block; kickoff and recap are short; logging happens during the hunt so triage is not archaeology.

What is a bug bash session?

A bug bash session is the event itself: the scheduled, time-boxed hunt on one build, including kickoff, hunt, and recap. It is not a single person’s screen recording — though recordings from the session are often how evidence is captured.