How to run a mobile bug bash: a 60-minute agenda and template

To run a mobile bug bash, pick one changed flow, give each tester a phone and a starting state, and reserve the last ten minutes to review the findings. Install the builds before the call. Ask testers to file issues as they find them, with the build number, the steps that triggered the bug and what they expected to happen.

What should you prepare before the bug bash?

Name a facilitator and choose a release risk narrow enough to explore in an hour. For a new checkout flow, the question might be “Can someone finish paying after they leave the app to approve a test payment?” Put the question in the invite alongside the iOS and Android build numbers, the test environment and the link where people will file issues. List known bugs so people can recognise them and add new evidence to the existing tickets. GitLab’s own bash guide also gives participants the objectives, access instructions, reporting route and known issues up front. GitLab’s UX Bash handbook

Ask each tester to open the build, sign in and check that their test data is ready before the session. If a scenario consumes a basket, invitation or one-time code, give each tester their own fixture or tell them how to reset it. One tester clearing a shared basket can look like a bug on someone else’s phone.

How do you divide the work across phones?

Assign each tester a starting condition and something to find out. Here’s an illustrative set of assignments for the checkout example.

Tester	Starting condition	What to explore
A	iPhone, signed in, fresh basket	Approve the test payment and return to the app. Check the confirmation and order history.
B	Android phone, signed in, separate basket	Cancel approval, return and try again. Check which basket details survive.
C	Android phone, existing install upgraded to the test build, saved basket	Start checkout, lock the phone before approval and unlock it. Check where checkout resumes.

These assignments spread the work. To isolate a platform difference, repeat the same failing sequence with equivalent test data on the other platform. Record the actual device, OS and build beside the result. If the group has more phones than it can use in an hour, pick coverage with the mobile device test matrix.

What does the 60-minute agenda look like?

1. 00–05 · Confirm setup. Read out the flow, show where to file an issue and have everyone verify the build number against the invite.
2. 05–40 · Explore. Start with the assigned scenario. Follow unexpected behaviour while the app is still in the failing state. File the issue or link an existing one in the run sheet.
3. 40–50 · Replay and capture. Ask a second tester to follow the most important report from its stated starting condition. If the failure only happened once, keep the original evidence and record what happened on the replay.
4. 50–60 · Triage. Assign someone to assess each potential release blocker. Link duplicate reports to the issue that will be worked on, keeping any distinct device or build evidence. Give unresolved reports an owner and a next check.

A tester who sees the checkout spinner stick should capture the screen before restarting. The issue should also say whether the test order appeared in order history and whether the test payment was approved. Those details help the person triaging it distinguish a missing confirmation from an incomplete order. Use test data and check attachments for sensitive details before sharing them.

What can you copy into the invite?

Mobile bug bash
Release risk:
iOS build / Android build:
Environment and feature flags:
Install links:
Test accounts, fixtures and reset instructions:
Known issues:
File findings here:
Facilitator / triage owner:

Tester | Device and OS | Starting state | Scenario | Result or issue link

Potential release blocker | Decision owner | Next check and deadline
Scenarios we didn't reach | Follow-up owner

Use the run sheet to track coverage and link issues. Write the steps, expected result and actual result in the issue itself so a developer can work from it after the invite is buried. The beta test issue template gives testers a shared format for the build, affected flow and evidence.