Bug bash
A bug bash is a time-boxed session in which people from across a team, not only testers, use a build together and report everything they find. It is usually scheduled shortly before a release. Its value comes from the variety of the people using the software rather than from the thoroughness of any one of them.
The longer version
A test suite checks the cases somebody already thought of, and a tester explores the ones their own experience suggests. A bug bash is the deliberate attempt to get past both limits by putting a designer, a support agent, a salesperson and an engineer in front of the same build at the same time. Each of them holds a different model of what the software is for, and the defects that surface are usually the ones that only appear when an unexpected assumption meets the product.
The session is time-boxed, commonly to an hour or two, because the format stops working when it becomes a shift. It needs a scope stated in advance, otherwise everyone tests the home page and nobody opens billing. The usual answer is to assign areas, or hand out short scenarios written as goals rather than as steps, so that participants find their own path to the same destination.
The output is the part teams underestimate. A bug bash generates a burst of reports in a short window, written by people who do not report bugs for a living, and a large share of them will describe the same defect in different words. Somebody has to deduplicate and triage that queue immediately afterwards, and a session without that follow-up produces a backlog nobody reads rather than a set of fixes.
It complements a QA process and does not substitute for one. A bug bash is unrepeatable, unmeasurable and dependent on who happened to attend, which are exactly the properties automated testing exists to avoid. It earns its place by finding a different class of problem: the confusing, the mislabelled, and the technically correct behaviour that nobody outside the team would expect.
Common questions
How long should a bug bash last?
One to two hours is the common length. The format depends on concentrated attention from people whose job is something else, and it degrades once participants start treating it as a shift rather than a session. Teams that want more coverage run a second bash on a different area rather than extending the first.
Who should take part in a bug bash?
People from outside QA, deliberately. Designers, support agents, sales engineers and product managers each bring a different model of what the software is for, and the point of the format is the variety rather than the headcount. Testers are usually better spent organising the session and triaging its output.
What is the difference between a bug bash and exploratory testing?
Exploratory testing is unscripted investigation by someone who knows the system well, and it can happen any day. A bug bash is a scheduled group event whose value comes from participants who do not know the system well. They find opposite classes of defect, which is why running one does not remove the need for the other.
When in a release should a bug bash happen?
Late enough that the build is feature-complete and stable, early enough that what it finds can still be fixed. A bash run the day before a release converts every real finding into an argument about whether to ship, which is the same failure mode as scheduling user acceptance testing too late.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.