Running My First 'Bug Bash'

· 3 min read

I closed out the first blog in this 3 part series saying that I was going to create a template Miro board in advance of the session. I felt that a well structured board would not only help me with setting the scene for everyone once the bug bash kicked off, but it would also, hopefully, ensure that the session was valuable for everyone.

Lining Everything Up

I set up a Miro board with the following sections:

1. Feature(s)

The Jira ticket links relevant to this particular bug bash/feature.

2. Out of Scope

Any thing we didn’t want people focusing on in the session. E.g. for ours we wanted to explore adding a single thing to a cart. Multiple items is a future feature and so, an out of scope feature was being able to add multiple items to the cart.

3. Risks Identified

Anywhere we thought there might be a problem but we didn’t get a chance to explore yet or we wanted to explore in more detail. Particularly helpful for mobile specific things if you think you have some device or operating system specific issues.

4. Environment

The environment everyone will be testing in. Is it a feature branch, production, etc. Also is it on Android or iOS.

5. Account details

We needed test accounts set up in advance for people to use to help reduce setup time during the session, the details of these accounts were added to the Miro board. Some of the developers who were more familiar with the feature could also set up brand new ones if they wished.

6. Charters

We set up a few charters based on the risks we’d identified. Not so many as to bias people but enough that if people attended from outside of engineering and didn’t know where to start, they had charters to give them a starting point.

As we’re completely remote, the link to the Miro board and any instructions to complete before attending were sent out in advance.

The Main Event

When the session officially started, we spent 10 minutes giving a run down of the feature, highlighting the charters and how they could help with inspiration, how we’d like people to report issues, how long we would spend exploring (half an hour) and how we would debrief at the end.

Luisa, the person who developed the feature, and I were available throughout the session for people to unmute and ask us questions when they needed to. We then spent 15-20 minutes debriefing at the end and outlining how people could raise any things they thought about after the session with us.

Learnings

I’d call this a huge success for my first ever Bug Bash. Next time I’m hoping to:

  1. Be more familiar with the feature before the session
  2. Send the Miro board out further in advance of the session
  3. Refine the Miro board to be leaner, there was a bit too much detail in sections of it.

I hope to blog about applying these learnings when I get a chance. Watch this space!

In an effort to keep my blogs shorter, I’ve split this story into 3 parts. Read part 1 and part 2.