A successful bug bash depends on gathering the right people and making it easy for them to contribute. The chapter explains that organizers should not try to handle everything alone: they need allies who can help with preparation, promotion, technical setup, facilitation, and follow-up. Stakeholders may also become allies, but the key is to identify who can actively support the event and clarify how their involvement benefits both the bug bash and their own work.
The chapter emphasizes planning participant involvement strategically. While a bug bash can be open to everyone, organizers should think about the kinds of feedback they need and actively encourage specific groups to attend, such as people with domain knowledge, language skills, accessibility expertise, customer support experience, or other relevant perspectives. Organizers should also work with allies and team leads to reach these target participants, remove scheduling obstacles, and ensure the event includes a useful mix of knowledge and viewpoints.
Finally, the chapter focuses on helping participants join with confidence. Organizers should confirm access to tools, environments, communication channels, and bug reporting systems, then prepare supporting information such as a simple FAQ. The public announcement should be sent early, clearly explain the purpose of the bug bash, state when and where it will happen, describe how to join, welcome all roles, and point people to more information or support. Once the announcement is shared and promoted by communication allies, the event becomes visible, participants can sign up, and the organizers can move on to preparing the testing materials.
Bug bash team with their primary tasks and involvement times mapped out. Notice the overlap in time and people. Be sure to keep track of who needs to know what and when!
Possible allies of Bash IT’s bug bash are marked in the organizational chart. Most of the top-level are communication allies: CEO Catherine and heads of Support, Finance, Engineering, and HR. The delivery team allies are possibly Tech Leads and Product Managers. The DevOps Lead may provide tech support. Meanwhile, the Head of Product and the Testing Lead are organizers.
Different participants bring in different knowledge. Additionally, they can “wear multiple hats” and bring multiple skills to the table.
Bash IT’s public bug bash announcement and invitation
Summary
Bug bash allies are a must: gather the people who will be supporting you hands-on. You’ll need allies to help you promote the event, prepare for it, provide tech support, run it, and prepare the office space.
Get strategic about your participants. Of course, you can invite everyone, but how can you both maximize attendance and the value you get from the event? Research and target your participants.
Consider access and ease of joining the event, as that will increase attendance.
Make sure to send a timely, engaging public announcement about a bug bash for your company so that people can book their calendars.
FAQ
Who should be involved in organizing a bug bash?The organizing team should include active, enthusiastic, and caring allies who can help prepare, promote, run, and support the event. Common allies include delivery team contacts, office support allies, a facilitator, tech support, and communication allies.What is the difference between stakeholders and allies?Stakeholders are people whose approval or support may be needed for the bug bash to happen. Allies are people who actively support the idea by helping with preparation, running the event, providing technical or logistical support, or advocating for the event. Sometimes stakeholders and allies are the same people, but not always.What do delivery team contacts do during a bug bash?Delivery team contacts help provide test scenarios, explain feature requirements, identify environment needs, answer questions during the event, and review findings afterward. They are often product managers, developers, tech leads, or anyone who knows the feature well.When should different bug bash allies be involved?Delivery team contacts should be involved continuously before, during, and after the event. Tech support should be briefed as early as possible to prepare environments and access. Office support should be involved once event requirements are known. Facilitators should be briefed before the event, and communication allies should be involved before the event to help promote it.How do you motivate allies who are assigned to help but are not enthusiastic?Start by establishing common ground and explaining the benefits of being involved. Show how the bug bash supports their goals, increases visibility, encourages collaboration, and may provide useful examples for performance reviews. Discussing details with allies can help them feel empowered and more motivated.How should you decide who your bug bash participants should be?Think about the kind of feedback you want from the event, then identify people whose skills match that goal. For example, if you want accessibility feedback, invite colleagues with accessibility expertise. If you want localization feedback, target multilingual participants. You can also ask allies for suggestions.Can a bug bash be open to everyone?Yes. A bug bash can be a company-wide testing event, and everyone can be invited. However, it is still useful to identify target participant groups so you can actively encourage the people most likely to provide valuable feedback to attend.How can organizers make it easy for participants to join?Organizers should ensure participants have access to the communication channel, test environment, bug tracking system, and main bug bash document. They should also provide clear instructions, help people get access before the event, clarify whether attendance is optional or encouraged, and make the announcement easy to understand.What supporting information should be prepared before announcing the bug bash?Prepare a short FAQ or supporting document explaining what a bug bash is, who can join, what participants need to prepare, how collaboration will work, what tools or access are needed, and what will happen to reported bugs after the event.What should be included in a bug bash announcement?A good announcement should include a catchy hook, the mission of the event, what will be tested, when and where it will happen, whether it is online or in person, the time zone, joining conditions, any access requirements, where to find more information, where to ask questions, and optionally any prizes or gamification details.
pro $24.99 per month
access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
Bug Bash ebook for free
