How to Run a Bug Bash

A bug bash is a short, scheduled session where people from across the team, not just testers, use one build of the product at the same time to find problems before customers do. To run one well you need five things settled in advance: a written scope, a stable build everyone can reach, test accounts and data, a time box of 60 to 90 minutes, and a charter for each person saying what to explore. During the session, one person keeps the reports flowing into one place. Afterward, a small group dedupes and triages them, and every real problem becomes a bug with an owner. The rest of this page is the plan, the templates and the triage.

What a bug bash is for

A bug bash is good at one thing: many different eyes on the same product at once. A designer notices the spacing, a support lead tries the thing customers always get wrong, a salesperson walks the demo path, and a developer from another team does what nobody on the feature team thought to try. It is not a substitute for a QA checklist, which checks known things methodically. Run the checklist first; the bash finds what the checklist did not imagine.

Without focus, these events fade into people clicking around. Mozilla’s own QA wiki is frank about this: its testdays↗ (opens in a new tab) stopped drawing the broad participation they once did and became “little more than using volunteers to ‘dogfood’ Firefox builds.” The cure is structure: a scope, a charter per person, and triage that ends in visible fixes, so people come back next time.

Planning: scope, build, accounts, time box

• Scope. Name the feature, flow or release under test, and write down what is out of scope. “The new reschedule flow on web and iPhone; not billing, not Android” saves half the noise.
• Build. Freeze one build and share how to reach it: a staging URL, or for mobile an invite to the beta. On iOS, Apple’s TestFlight↗ (opens in a new tab) lets you add up to 100 internal testers from your team, and external testers once the build has passed beta review.
• Android. Google Play’s internal testing track↗ (opens in a new tab) distributes a build to up to 100 testers for initial quality checks, which fits a team bash.
• Accounts and data. Create test accounts for each role and fill them with realistic data before the day. Anything involving payments should run in a sandbox; Stripe’s testing docs↗ (opens in a new tab), for example, describe test cards whose transactions do not move funds.
• Time box. 60 to 90 minutes of testing, plus 10 minutes to start and 10 to wrap up. Longer sessions produce tired, repetitive reports.
• Where reports go. One place, set up before the start, with the template pinned. Reports in chat threads get lost.

Roles

• Host: owns the plan, opens the session, hands out charters, keeps time and closes it.
• Testers: everyone else. A mix of roles tends to see more than a room of engineers.
• Triager: one or two people who read reports as they arrive, ask for missing steps while the reporter is still there, and merge obvious duplicates.
• Build contact: a developer who can answer “is this broken or is my account wrong?” and fix a blocking environment problem in minutes.
• Decider: the person who, afterward, sets priority and says what blocks the release. Often the product owner. It is always a person.

A charter for each tester

A charter is two or three lines that give one person a mission: what to explore, with what, and what kind of problem to look for. It keeps ten people from all testing the sign-in page, and it gives a newcomer somewhere to start. Write one per person or per pair, and rotate halfway through if the session is long.

Charter [number]: [who]

Explore:     [area, flow or screen]
With:        [account / role, device, browser, data]
Looking for: [the kind of problem: data errors, layout,
             permissions, slow screens, confusing wording]
Out of scope: [areas to ignore]
Time:        [minutes]   Report to: [where]

Charter 4: Luis (support lead)

Explore:     Rescheduling a booking the day before it starts
With:        "Customer with 3 bookings" account, iPhone, Safari
Looking for: anything a customer would email us about:
             wrong times, missing confirmations, unclear wording
Out of scope: payments, admin screens
Time:        45 minutes   Report to: the bug bash board

Filing during the session

Ask for the same short format from everyone: a title that names the problem, steps, expected, actual, device and browser, and a screenshot. The full field list is in the bug report template; for a bash, the short version is enough as long as the triager can reproduce it. One problem per report. Guesses about the cause go in a separate line marked as a guess.

Title:    [what goes wrong, where]
Charter:  [number]
Steps:    1. ...  2. ...  3. ...
Expected: [what should happen]
Actual:   [what happened; exact error text]
Device:   [device, OS, browser]   Account: [test account]
Evidence: [screenshot or recording]

Triage afterward

Hold triage the same day or the next morning, with the host, the triager and the decider. Work through the reports once, in this order:

1. Merge duplicates. Keep the clearest report, add the others’ details to it, and credit everyone who found it.
2. Reproduce. Anything nobody can reproduce goes back to the reporter with a question, not to the bin.
3. Separate bugs from requests. “It would be nice if…” is a feature or enhancement, not a bug, and goes to the backlog.
4. Set severity and priority. Severity is how bad the effect is; priority is when the team will fix it. They are different calls, explained in bug severity vs priority.
5. Say what blocks the release, and tell the testers what happened to their reports. People who see their bugs fixed come to the next bash.

A remote or async bug bash

A distributed team can run the same event across time zones. Publish the scope, build, accounts and charters at the start of a 24- or 48-hour window, ask each person to spend a set time on their charter within it, and keep a live channel for the build contact. The trade-off is the triager: reports arrive while the reporter is asleep, so the template has to be strict enough that nobody needs to ask a question. Tools help here. Microsoft’s Test & Feedback extension↗ (opens in a new tab) for Azure DevOps, for example, captures screenshots and recordings during an exploratory session, shows similar existing bugs, and exports a session report to share.

Letting an AI assistant tidy the reports

The tedious part of a bash is the pile at the end: forty reports, a third of them duplicates, half missing a device. An AI assistant connected to the board is good at this part. Ask it to group reports that describe the same problem, list which reports lack steps or a device, rewrite titles so they name the problem, and suggest a severity for each with a one-line reason. It should propose, not act: the decider reads the groups, merges what really is the same, and sets priority and the release call. The assistant does not decide which bugs matter.

Read every task filed today with "bug bash" in the note.
1. Group the ones that describe the same problem. For each
   group, name the clearest report and list the others.
2. List reports missing steps, expected/actual or a device.
3. Suggest a severity for each (data loss / main path blocked /
   workaround exists / cosmetic) with a one-line reason.
Do not merge, close, reprioritize or edit anything. Give me the
list; I will decide.

Running it on fenbs

On fenbs, every report is a task of kind bug with a BUG- ref, and the note holds the steps. Testers from outside the team can be added to a team board with the suggested Reporter role, which adds tasks and comments and edits only their own, so reports arrive under each person’s name and nobody in that role can edit anyone else’s task. If people collected findings in a shared document instead, paste them into Add many with a bug: marker on each line, and they are previewed before anything is created.

Duplicates have a guard on the way in. When an AI assistant files a task with fenbs_create_item and an open task looks like the same thing, nothing is filed and the likely matches come back, so the assistant comments on the existing bug instead of adding another. Priority is set from 1 to 10, 1 the most urgent, and History records who changed what. A standing call such as “a bug that loses data always blocks the release” belongs on the Decisions and rules page as a rule, where the person who made it is recorded as the decider and every connected assistant reads it first.