How to run a bug bash that actually finds bugs

Twenty people. Two hours. Free pizza. At the end, 63 tickets in the backlog.

The next morning, someone sorts them. Forty-one are duplicates of each other. Nine are "works as designed". Six are feature requests. Four cannot be reproduced because nobody wrote down what they did. Three are real bugs.

Three real bugs cost forty hours of company time, and the QA lead spent the whole next day cleaning up. That is why teams try a bug bash once and never again.

The problem was never the idea. It was the lack of a plan.

Short version

Assign every person a specific area. Unassigned people all test the login page.
Deduplicate live, during the session, not the next morning.
Score for quality of report, not number of tickets, or you will drown in noise.
Book the triage meeting before the bug bash, not after.
A bug bash finds different bugs than QA does. That is the point, not a criticism of QA.

What a bug bash is, and what it is not

A bug bash is a scheduled session where a mixed group of people tests the product together for a fixed time. Developers, designers, support, sales, and product managers all take part, not only testers.

It works because those people are not QA. They have different habits, different machines, and different assumptions. A support agent knows what customers actually do. A designer notices spacing nobody else sees. A salesperson clicks straight to the feature they promised a client last week.

A bug bash is not a replacement for testing. It is a wide, shallow sweep that catches what a narrow, deep process misses. Run one before a big release, after a large redesign, or when a feature is nearly done but not shipped.

Before the day

Preparation decides whether the session works. Most of it takes about two hours in total.

One week before:

Pick the scope and write it in one sentence: "The new subscription billing flow, web only, Chrome and Safari."
Book 90 minutes and invite 8 to 15 people. More than 15 and dedup becomes unmanageable.
Tell people it is testing, not a demo. Some will expect to watch.

Two days before:

Prepare test accounts. One per person, named clearly: [email protected] through [email protected]. Shared accounts cause chaos, because two people editing the same record produce bugs that are not bugs.
Load real-looking data. Empty accounts hide most bugs. Add orders, long names, an account with 400 items, and one with a name like "Jean-Luc O'Brien-Smith".
Freeze the build. Deploy staging.example.com the day before and do not touch it. A deploy mid-session invalidates every report.
Write the reporting template and pin it. Title, steps, expected, actual, screenshot, browser.

The day before:

Send the mission list, so people arrive knowing their area.
Do a five-minute smoke test yourself. If checkout is already broken, everyone reports the same thing and you lose the session.

The agenda

Here is a 90-minute agenda that works. Print it or paste it into the invite.

Time	What happens	Who
0:00 - 0:10	Kickoff. Scope, missions, rules, how to report	Host
0:10 - 0:15	Everyone logs in and confirms their account works	All
0:15 - 0:55	Round 1. Test your assigned mission	All
0:55 - 1:05	Break. Triage pair starts the first dedup pass	All
1:05 - 1:30	Round 2. Swap missions with the person next to you	All
1:30 - 1:45	Wrap-up. Top findings read out, thanks, next steps	Host

Two details matter more than they look. The swap in round 2 is the highest-value 25 minutes of the session, because a second person on an already-covered area brings different assumptions. And the triage pair, one QA person and one developer, do not test at all. Their whole job is reading incoming reports live, from the ticket queue.

Give everyone a mission

Unassigned people test the same three screens. Missions fix that in one line each.

Good missions from a real billing bug bash:

Amir: upgrade and downgrade between plans, including mid-month.
Lena: everything to do with failed payments and card declines.
Sam: the invoice list with 200 invoices. Filtering, sorting, pagination, export.
Dee: mobile Safari only. Same flows, small screen.
Tom: try to break it with bad input. Very long text, emoji, <script>alert(1)</script>, negative numbers.
Priya: the empty state. Brand new account with nothing in it.
Marcus: keyboard only. No mouse for the whole session.
Rosa: slow network. Chrome DevTools set to Slow 4G the entire time.

Notice that three of these are conditions, not features. Those missions consistently find the bugs everyone else walks past.

Give each person one sentence, written down. Do not let anyone say "I'll just have a look around".

Deduplicate live

This is the single biggest change between a bug bash that works and one that does not.

Set up a shared channel or a live document. As reports come in, the triage pair does three things:

Read every incoming ticket within a couple of minutes.
Post the headline publicly. "Found: invoice export gives an empty CSV when a filter is on (BASH-14)."
Close duplicates immediately by linking to the original.

Then add one rule everyone follows before reporting: search the channel for one keyword from your bug. Not the whole sentence, one word. "export". "decline". "upgrade".

That single habit removes most duplicates before they exist.

Reports also need to be fast to file, or people stop filing them. If a report takes five minutes to write, a designer with a small layout bug will simply not bother, and small layout bugs are exactly what they are there for. Whatever route you pick, make it one click from the page. Browser tools such as Crosscheck capture the screenshot, console logs, network requests, and browser details automatically when you report from the page, which keeps non-QA participants reporting instead of giving up halfway through a form.

Tag everything from the session with the same label, such as bug-bash-2026-07. You will need it tomorrow.

Scoring, done carefully

Prizes make bug bashes fun. They also decide what people do, so pick the measure carefully.

Counting tickets is the obvious choice and the worst one. It rewards volume, which means duplicates, feature requests, and "the spacing here is 2px off" filed nine times.

Score on what you actually want:

Best report of the day. Clear steps, evidence, a genuinely useful title. One winner.
Most serious bug. Judged by the triage pair, not by a vote.
Best edge case. The one nobody would have thought of.
Best non-QA find. Encourages the support and sales people to keep coming.
Best "not a bug" find. Confusing behaviour that is technically correct. These become design tickets.

Award them in the last 15 minutes, out loud, with the reason. Fifty pounds of vouchers is plenty. The recognition does more work than the prize.

One thing to avoid: never score by team or department. It turns a shared exercise into a competition between the people who build the product and the people who test it.

What to do with the results

The bug bash is not the deliverable. What happens next is.

Book the triage meeting before the bash. Put it in the calendar for the next morning, 45 minutes, with QA, the product manager, and the tech lead.
Sort every ticket into four piles. Fix now, fix later, not a bug, and not our scope.
Assign an owner and a date to everything in "fix now". A pile with no owner is a pile that never moves.
Reply to every reporter. One line each. People who never hear back do not come to the next one.
Look at the "not a bug" pile properly. If five people reported the same correct behaviour as broken, that is a design problem wearing a costume.
Post a summary within 24 hours. How many reports, how many unique, how many are being fixed, and the three best finds by name.
Ask one question in the summary. "What slowed you down?" The answers shape the next session.

Then look at the shape of the results and learn from it. If most findings came from the slow network mission, your regular testing does not cover network conditions. If most came from mobile Safari, your browser coverage has a hole. The pattern in the bugs tells you more than the bugs do.

Common failure modes

The build breaks at minute five. Smoke test first, and have a rollback ready.
Everyone reports the same top-of-page bug. Fix or announce known issues before you start.
Managers watch instead of test. Everyone tests, including the host after kickoff.
No time limit. Sessions that "run until people are done" fade out with no ending and no summary.
Bugs go into a channel and never into the tracker. Reports that live only in chat are lost by Friday.
Running one every week. Enthusiasm dies. Once a quarter, or before a significant release, is enough.

Frequently asked questions

How many people should join a bug bash?

Between 8 and 15. Fewer than 8 and you lose the variety that makes it worthwhile. More than 15 and the triage pair cannot keep up with the incoming reports, which is exactly how you end up with the duplicate pile.

Should developers test their own code?

They can, but put them on someone else's area. People rarely find bugs in code they wrote, because they test the paths they already thought about. Swap them onto a neighbouring feature instead.

What if we do not have a staging environment?

Use a feature branch deploy or a preview build. What you cannot do is run it on production with real customer data. Someone will delete something that matters within the first ten minutes.

Can a bug bash work with a remote team?

Yes, and remote sessions often run better. Use one video call kept open, one chat channel for reports, and the same missions and timings. The chat channel makes live dedup easier than it is in a room.

How often should we run one?

Once a quarter as a habit, plus one before any release that carries real risk. More often than that and attendance drops, because it stops feeling like an event and starts feeling like a meeting.