Bug Bash - Template
- Anto Sgarlatta
Bug Bash Fundamentals
What is a bug bash?
It’s a collaborative event where the whole team, no matter what their role is, comes together to try to “break” the application in creative ways ahead of a release. The goal is to find as many bugs as possible in a short period of time, and since every person in the team will have their own unique perspective and use the application in different ways, there are better chances of uncovering issues, defining how severe they are and if needed fixing them ahead of the release. It’s also a great opportunity for people to spend some time familiarizing themselves with the application and putting themselves in the shoes of one of our users. And last but not least, breaking things can actually be fun! By doing bug bashes often, we’re cultivating a blame-free culture where we take bugs as a chance to bond as a team, learn and improve.
How do I participate?
If you’re willing to collaborate with this bug bash, please write your name down in the Participants section. If possible add details about what language(s) you’re using when testing the app, as well as which user role(s) you’re logging in as. This will help us know if there are any languages or roles not currently being covered by anyone.
Read through the scope of what we’re testing in the Scope section. The scope will usually be defined based on what kind of changes we are pushing out on the upcoming release and it’s a guidance on which are the main things to keep an eye on. That being said, if you do find any bugs that are unrelated to the scope, feel free to report them anyway.
If the bug bash is done synchronously, there’ll be a meeting where we all come together and test at the same time with a time box. If it’s done asynchronously, we’ll aim to have the session open for enough time that people in different timezones are able to participate. In that case, feel free to participate whenever you can and have the time and to time box depending on what your schedule looks like. Everything helps, so even if you only have limited time to test, you might discover something that nobody else has found before. Information on the timing of the meeting or asynchronous session can be found in the Session details section
What do I do if I find a bug?
First off, congratulations on finding it! To report the bug, head over to the Bugs section and add a new row in the table. The row should include your name and a brief description of the bug, on the Details field please add as much information as possible. Please provide reproduction steps and expected/actual behavior, and if you have the time, screenshots or video recordings of what you encountered will be extremely helpful. You don’t need to fill out the Pre-existing, Priority or Blocker fields as those will be filled out once the session is over.
If you spot a bug and you see someone else has already reported it and it’s on the table, you can go ahead and just add your name to the “Also seen by” column to mark that the bug is encountered frequently, without having to write down all the details again.
What happens after the bug bash?
Once the bug bash session is over, the team will go over the list of bugs that were found and prioritize them. For each issue, we’ll try to answer these three questions:
Was this bug caused by the change we’re aiming to push out on this release, or does it currently exist in production?
How severe and how frequent is this bug, or in other words, what’s the priority for fixing it?
Should this bug block the upcoming release?
No matter the result, if the issue found is something we’d like to fix eventually, we’ll create the corresponding ticket in Jira and add it to the Backlog. If we come to the conclusion that one or more bugs are actually blocking the upcoming release, we’ll add those tickets to the current sprint and give them the highest priority. If no bugs are found that are blocking, we’ll proceed with the release process as normal and work on the reported issues in future sprints depending on their priority.
Participants
Name | Language(s) | User role(s) |
|---|---|---|
E.g.: @Anto Sgarlatta | E.g.: Spanish, English | E.g.: Farm Owner, Farm Worker |
|
|
|
|
|
|
|
|
|
|
|
|
Scope
This bug bash will be focused on testing [Hotfix/Release X.Y.Z]. The purpose of the patch is to …:
[Jira links]
The main focus of the session should then be on …
User Stories
[Link to appropriate sections of the Sanity Script here if there are any]
Known Issues
Session Details
Synchronous or asynchronous? |
|
|---|---|
When? |
|
Where to test? | Prod/Beta/Local |
Bug Reports
Reporter | Description | Details | Pre-existing? | Priority | Blocker? | Also seen by |
|---|---|---|---|---|---|---|
E.g.: @Anto Sgarlatta | E.g.: The SSO button is not clickable | E.g.: Repro steps
Expected Should navigate to the Google page to choose an account Actual Nothing happens Screenshots/videos
| E.g.: No | E.g.: High | E.g.: Yes | E.g. @Joyce Sato-Reinhold |
|
| Repro steps 1. 2. Expected
Actual
Screenshots/videos
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|