Igor
A bug bash is a time-boxed hunt for bugs on one named build, with people from outside the feature's authors, followed by triage the same day. It is not a weekly bug meeting, and it is not a test pass with a script. Block two hours. Spend the day before on the build, the scope and the place bugs will be filed. If you skip the same-day triage, you have a pile, not a backlog.
What a bug bash is, and is not
The hunt is exploratory. You give people areas to look at, called charters, and you let them wander when something looks wrong. You do not hand them a spreadsheet of expected results and call it a bash. That spreadsheet is a test pass. It can be useful, and it is a different meeting.
Triage is the other meeting people mix in. Triage decides what happens to bugs that already exist: fix now, fix later, ask for more, merge, or close. A bash creates the bugs. The 15-minute triage agenda is how you finish the afternoon. Do not invent a second set of outcomes in the recap.
When to hold one
Hold one before a release the team is nervous about, or after a large change that the authors have only tested along the path they built. A bash is a poor weekly ritual. People stop finding anything, and the charters go stale.
Do not hold one on a build that is still moving. If someone is merging during the hunt, half the findings are already fixed and the other half cannot be retried. Freeze the build, or pick a time when no one is shipping to that environment.
Eight to twenty people is enough range for a product team. Fewer than that and you are doing a normal test session. More than that and the moderator cannot keep the environment up or stop duplicate reports of the same button.
The day before
The hunt fails in the first ten minutes if people cannot log in. Do this the day before, not in the kickoff.
- Name the build. URL, version or commit, and which feature flags are on. Write it at the top of the invite.
- Write the scope in two lists. In scope: the flows you are willing to fix before release. Out of scope: known unfinished work, so people do not file it as a surprise.
- Write five to twelve charters. A charter is a question, not a script. "Can a new customer finish checkout with a discount code?" is a charter. Forty numbered steps is a test case.
- Publish known issues. People re-file what you already know, then feel ignored. A list prevents that.
- Seed accounts and data. At least one empty account, one with real-looking history, and an admin if the scope includes admin. Shared passwords in the invite are fine for a staging site and a bad idea for production. Prefer a staging environment.
- Pick one place to file. One Jira project, one Linear team, one GitHub repo, or one inbox. Chat is for "the staging site is down", not for the bugs.
- Say how to capture evidence before anyone arrives. The next section is the minimum. A screenshot of the whole desktop with no URL is not it.
Three roles
Moderator. Runs the clock, assigns charters, and stops the room turning into a design debate. Usually the person who called the bash. They do not also fix the environment.
Stager. Owns the build. Resets data, answers "I can't log in", and says no if someone asks to deploy a fix in the middle of the hunt. A developer who did not write the feature is a good choice. The author of the feature can attend as a tester, not as the person everyone interrupts.
Testers. Everyone else: QA, a developer from another area, design, support, someone who talks to customers. They file as they go. A dedicated note-taker is a sign the filing path is too slow. Fix the path rather than adding a person to retype bugs after the fact.
The two hours
| Time | What happens |
|---|---|
| 10 minutes | Kickoff. Build URL, out of scope, known issues, where to file, how to capture. Assign charters so two people are not both stuck on login. One walkthrough of the happy path. Then stop talking. |
| 60 to 90 minutes | Hunt. Testers follow a charter, then follow anything odd. The moderator watches the clock and the duplicate titles. The stager only speaks when the environment breaks. |
| 15 to 20 minutes | Triage. Not a demo of every bug. Deduplicate, mark what blocks release, name an owner. Use the triage outcomes. End while people are still in the room. |
If the hunt runs long, cut it. A late triage is how findings stay in a chat scroll. Protect the last twenty minutes the way you protect the start.
What each finding must contain
A bash produces a lot of thin tickets if you do not say what "filed" means. Each finding needs six things. If one is missing, the tester spends one more minute, or the bug does not get filed.
- A title with the object, the page and the wrong result. "Discount line shows 10% but the total does not change on checkout." Not "checkout bug".
- The account and the data. Which seeded user, which code, which product. "I used the empty account and SAVE10."
- What they did, in a few steps, starting from a place someone else can open.
- What they expected, in one sentence. A bash without expected results fills up with preferences.
- What they saw, including the exact error text if there was one.
- Evidence. The element they mean, a screenshot with that element marked, and the console error or the failed request if the bug is not purely visual.
Preferences ("I don't like this label") go on a separate list, or they drown the defects. Say that in the kickoff.
If people are filing through SnagRelay, pointing at the element collects the screenshot, the console errors and the requests for them, on the page they are already on. They still have to write the expected result. The tool does not know what the charter asked for. The report can land in the tracker you named as the one place to file, which is the point of naming one place. It will not dedupe the pile. A person does that in triage. There is no automatic duplicate detection to lean on.
Triage before people leave
Sort the new tickets. Merge the ones that are the same button. Mark which ones block the release. Give each remaining ticket an owner, or explicitly park it. Then stop.
The rules and the five outcomes are already written up for a shorter meeting. Follow that agenda rather than restating it: the 15-minute bug triage. Severity and priority are decided there, not by whoever typed fastest during the hunt. If you need the difference, it is in bug severity vs priority.
Send a short recap the same day: how many findings, how many were duplicates, which ones block release, what you did not look at. The last line is what you schedule the next bash against. Unexamined scope is how the same bash gets repeated without covering the rest of the product.
Copy-paste sheet
BUG BASH
Build: [URL, version, flags]
When: [date, two-hour block]
Moderator: [name]
Stager: [name]
File in: [one tracker or inbox]
IN SCOPE
- [flow]
OUT OF SCOPE
- [known unfinished work]
KNOWN ISSUES
- [already filed]
CHARTERS
1. [question]
2. [question]
EACH FINDING
- Title: object, page, wrong result
- Account and data
- Steps
- Expected
- Actual, with the error text
- Element, screenshot, console or request
SAME-DAY TRIAGE
- Duplicates merged
- Release blockers named
- Every other ticket owned or parked
- Recap sentA finding that does not match that block waits, or it is a note, not a bug. The templates in bug report templates are there if a tester wants a fuller ticket after the bash. During the two hours, the six lines are enough.
FAQ
How long should a bug bash last?
Block two hours. Ten minutes to start, sixty to ninety to hunt, and the rest to triage. A hunt with no triage at the end produces tickets nobody owns.
How is a bug bash different from a triage meeting?
A bash finds bugs on one frozen build. Triage decides what happens to bugs that are already filed. Run triage at the end of the bash, using a short agenda, instead of mixing the two conversations.
Who should be invited?
People who did not write the feature, plus QA, and someone who sees the product the way a customer does. The author can attend as a tester. The person who keeps the environment up should not also be the moderator.
What if two people file the same bug?
That is normal. Merge them in the same-day triage and keep the report that has the better evidence. Do not stop the hunt to debate duplicates in the room.