Quick answer: A four-hour pre-launch bug bash catches the bugs that demo testing misses. Here's the structure: scope by area, pair testers, log via SDK, freeze in T-48h.
Most indie launches go out with three or four bugs that would have been caught by an hour of focused testing on the gold candidate.
Scope into rooms
Divide the game into 6-10 'rooms' (first hour, mid-game systems, settings, save/load, etc.). Assign 2 testers per room. Time-box each room to 30 minutes.
Pair drivers and observers
One person plays; one watches and writes. Single-player bug bashing misses 40% of repro steps because the player is too engaged to log accurately.
Use the SDK, not a spreadsheet
An in-game bug report button captures system info, repro state, and a screenshot. A spreadsheet captures opinion. You want both, but only one survives triage.
Freeze code 48 hours out
The bug bash is for bugs already in the code. New features in the last 48h create new bugs faster than you can find them.
“Bug bashes find the bugs everyone assumed someone else would notice.”
Buy pizza. The structure matters but morale matters more - the bash that runs long because people are engaged finds more than the bash that ends on time.