A bug bash is a timeboxed session where people from across a team — engineers, designers, support, product — test the same build at the same time to find bugs before release. Most guides describe an idealised version. This one looks at four documented cases from Microsoft, Dropbox and GitLab, what each does differently, and what to do with the bugs afterwards.

What is a bug bash?

A bug bash is an organised event, not a testing technique. A group of people, usually including non-testers, spend a fixed block of time exploring the same build with the goal of surfacing defects that structured testing missed.

Three things define it:

It is timeboxed. An hour, ninety minutes, an afternoon. Not "this sprint".

It is collective. The value comes from people who do not normally test the product — a support agent who knows what customers actually do, a designer who notices a broken state a tester walks past.

It has a defined scope. One build, one area, one set of accounts. Without that, half the room tests the same happy path and nobody touches the new feature.

Bug bash vs exploratory testing

These get used interchangeably and should not be.

Exploratory testing is a technique — simultaneous learning, test design and execution, performed by one person at a time.

A bug bash is an event during which many people may use that technique at once.

You can run exploratory testing without a bug bash, every day, alone. You cannot run a useful bug bash without something that resembles exploratory testing, because a group following pre-written scripts is doing execution, not a bash.

The related terms QA sprint and testing day are used loosely across the industry with no settled definitions, so we are not going to draw boundaries that do not exist.

How four companies run bug bashes

Documented practice varies more than the guides suggest.

Microsoft: an annual accessibility bug bash

Microsoft runs an annual bug bash focused on neurodiversity and accessibility. Participants work through scenarios asynchronously rather than in one room, record their screens, describe the friction they hit, and complete a survey. The feedback goes to the relevant product groups.

Two things are unusual here. The session is asynchronous, which removes the scheduling problem that kills most bug bashes. And the output is friction descriptions and screen recordings rather than bug tickets — appropriate, because accessibility problems are often not defects in the ticketing sense.

Source: Microsoft Inside Track (July 2026)

Dropbox: weekly, straight into Jira

Dropbox runs a weekly bug bash. An analyst and a product manager drop screenshots of problems into Jira, and the findings feed decisions about cohort releases and release blockers.

The weekly cadence is the interesting part. Most teams treat a bug bash as a pre-release ritual; running one every week makes it a routine input to release decisions rather than a last-minute safety net.

Source: Atlassian customer story

GitLab: label-driven triage

GitLab's approach shows up in how findings are organised rather than in how the session runs. Issues carry an Event - Bug Bash label, are assigned a severity of critical, high, medium or low, and are attached to a milestone, producing an ordered list rather than a pile.

This addresses the failure mode nobody plans for: a bug bash that generates sixty tickets, of which forty are duplicates and none has an owner.

Source: GitLab

Microsoft again: the bug bash as a release gate

Microsoft's Experimentation Platform team describes a sequence before launch: bug bash → pilot customers and initial beta → A/B test. The bug bash is the first gate, not the last check.

That ordering matters. Running a bash after beta means finding problems that customers have already seen.

What is not publicly documented

We looked for detailed procedural accounts from Shopify, Spotify and Slack and did not find any. Absence of a public write-up is not evidence they do not run bug bashes — only that the process is not documented publicly.

Where the "Microsoft invented it" claim comes from

You will find many articles stating that Microsoft invented or popularised bug bashes in the 1990s. We could not find a primary source for that claim.

The earliest credible source we found is a post on the Google Testing Blog from 21 June 2008 by Ross Smith, then Director of Test for Microsoft Windows Core Security. He describes bug bashes as an already-established practice — he does not claim Microsoft originated them.

Source: Google Testing Blog

So the honest version: the practice was well known inside Microsoft by the mid-2000s and was written about publicly by a Microsoft test director in 2008. Whether it started there is undocumented.

This matters less for accuracy than for what it says about the rest of the material available on this topic, most of which repeats the claim without checking it.

How to run a bug bash: process and steps

Before

Pick a scope and write it down. One feature, one flow, one platform. Also write what is out of scope — that sentence prevents half the wasted time.

Freeze the build. Everyone tests the same thing. A build that changes mid-session makes results unreproducible.

Prepare accounts and data. Test accounts, seeded data, permissions. Nothing burns fifteen minutes faster than eight people trying to sign up simultaneously.

Show one example bug report. Not a template document — one filled-in example. It sets the standard for detail more effectively than instructions.

During

Assign three roles. A facilitator who keeps scope and time. A triager who watches incoming reports for duplicates in real time. A developer on standby for questions like "is this expected".

Log everything in one place. A shared board, a Slack channel with a fixed format, a Jira component. One place. Bugs reported verbally do not exist. If the team already uses a dedicated reporting layer, keep the bash inside the same workflow rather than creating a temporary spreadsheet; our guide to test reporting tools covers the main options.

Rotate halfway. People who have been staring at the same screen for thirty minutes stop seeing it. Swapping areas at the midpoint reliably surfaces a second wave.

Triage live, not later. Duplicates removed while the reporter is still available cost a minute. The same duplicates found three days later cost an hour.

After

Deduplicate first. Before prioritising, before assigning.

Assign owners and severity immediately. A bug bash where nobody owns the output produces a list that is quietly closed at the end of the quarter. GitLab's label-plus-milestone approach exists for exactly this.

Report back to participants. People who spent ninety minutes finding bugs will not come to the next session if they never learn what happened. One message with counts — found, confirmed, fixed, deferred — is enough.

A practical 90-minute bug bash agenda

A bug bash works better when participants know what happens next. For a synchronous 90-minute session, this is a useful default:

The timing is not sacred. The important part is reserving time for live triage and ownership instead of spending the entire session finding more issues than anyone can process.

What to do with the bugs you find

A bug bash produces a list of confirmed bugs. The ones worth keeping are the ones that could come back — so record each of those paths as a regression test while the steps are still fresh. If the same path matters on every release, it belongs in the normal regression testing process rather than in a one-off bash.

Since half the room is usually non-technical, a recorder that captures the click path without code means the person who found the bug can be the one who writes the test for it. That removes the usual handover, where a tester tries to reproduce a defect from a two-line description written by someone in a different team.

Not every bug deserves a test. Use a simple filter: would this have been caught by a test we could have written before the bash? If yes, write it now. If it was a one-off state that cannot recur, close it and move on.

Once bugs are logged, they follow the ordinary bug life cycle — a bug bash changes where defects are found, not what happens to them afterwards. Where teams disagree about whether something is a defect at all, our guide to bug vs defect covers the distinction.

When a bug bash is the wrong tool

When the build is unstable. If the application crashes on launch, you will collect sixty reports of the same crash. Fix it first. A quick automated smoke test before the session is a cheap way to catch that class of blocker.

When you need coverage, not discovery. A bug bash finds what structured testing missed. It does not replace structured testing, and using it that way produces confidence without coverage. If the question is "how much of the product did we actually test?", track test coverage instead.

When there is no capacity to fix. Finding forty bugs nobody will triage demoralises everyone who took part.

When the scope is the whole product. Attention scatters, everyone tests the login page, and the new feature goes untouched.

When it is the only testing you do. A bug bash is a supplement. Teams that rely on it as their main quality process have a staffing problem, not a process one — as our guide to QA skills covers in more detail.