How We Reduced Testing Delays By Leveraging Mob Testing at Storyblocks
Has testing a feature you were eager to roll out taken forever due to playing telephone with stakeholders? As Storyblock’s first dedicated QA professional and new to testing myself, I felt the pain of this again and again. This is how we used Mob Testing to improve our communication and reduce our feature deployment time.
Juggling Stakeholders
A feature would be ready to test but would require input from Design to make sure it looked okay, Product to make sure the requirements were matched, Customer Service to make sure it wasn’t confusing to the end-users, QA to check everything was working and there weren’t any defects, and Engineering to figure out how best to efficiently address all the issues these teams found. All of these stakeholders would send the feedback my way to add to a Google spreadsheet where we track issues or make decisions among themselves about how to proceed (without telling any other stakeholders). I was the person who had to ask everyone to clarify what they meant or to add screenshots to show where the specific issue showed up. Then, we’d have to do it again to make sure it was ready to deploy after the engineer fixed things up. Yeah, it was frustrating.
One day while attempting to improve the efficiency of this process and help bridge the communication gaps, I threw a meeting on the calendar of all these stakeholders and decided we needed to be in the same room to sort this test stuff in real-time. This is how we organically stumbled upon Mob Testing.
What is Mob Testing?
Similar to pair programming, Mob Testing is a testing approach where a team works together on a single task on one computer at the same time. There is a set rotation of who is in control of the mouse and keyboard. The input comes from the group as a whole and everyone’s ideas are valued. To have a successful mob testing session, the interactions hinge on guiding principles of kindness, consideration, and respect.
How We Use Mob Testing at Storyblocks
When we have a complex set of requirements for an update or a new part of our product, a meeting is scheduled with all relevant stakeholders. In the meeting, we use a shared Google spreadsheet to track defects, poor experiences, or points that require clarification. We walk through the requirements, asking questions and exploring the testing environment. While we don’t always switch off who is in control, we do provide everyone with a chance to speak up and give input as to where to navigate to next. If an issue is found, it’s discussed with the group and we decide when and how it should be addressed.
Recently, we’ve also begun creating temporary Slack channels specifically to discuss the software under testing where stakeholders can ask questions and respond to feedback or follow-ups. This works well should you not be able to get everyone in the same room for a mob testing session but still want everyone to be knowledgeable of how the testing process is going.
Having A Plan
One of the most important things we learned through numerous mob testing sessions is to have a plan going into the mob session. Make sure you come into the meeting with all environments set up already with the appropriate data needed to test the feature, a testing plan which should include some time for exploratory testing (if that’s not what the meeting is dedicated to entirely), and someone to keep the discussion on course. Once the testing session is done, come up with next steps for follow up and determine if another mob session is necessary or if feedback could be provided in a temporary Slack channel or on the feature’s ticket. Having these steps in place keeps the meetings an efficient use of everyone’s time.
Benefits of Mob Testing
1. Resolves Communication Problems — With everyone in the same room at the same time, it makes it easier to discuss issues that are found and how to resolve them. As a result, things get fixed quicker with less confusion. Additionally, it prevents the game of telephone when something is said in Slack or in a one-on-one conversation but not properly communicated and what ultimately gets back to the teams is not accurate.
2. Lets Teams Not Directly Involved in Building Features See Features Sooner— By having more eyes from teams who otherwise may not see the feature until it goes into production, you help to reduce the total number of defects found before the feature goes into production. For example, when we include our customer service team in the mob sessions, they tend to note copy and flows that could be confusing to customers.
3. Helps Improve Future Projects — Especially in larger companies, you may run into situations where deploying a feature directly impacts a feature that is currently being tested or has already been rolled out. By having stakeholders who work on different projects in the same room, you may be able to flag a part of the product you are currently testing that would impact something that stakeholder is working on.
4. Helps to Build Relationships — As stakeholders from different departments get to work together, especially in an open positive environment, they begin to cultivate relationships that may not otherwise exist. This helps to open communication channels and makes it easier for members of different teams to comfortably communicate with one another.
A Helpful Hint For Success
Add A Testing Session Option On the Feature Ticket To Get Everyone Thinking About Mob Testing — We recently rolled out an option when creating a feature ticket in Jira where there is a checkbox that says “Group Testing” which can be checked by the PM, engineer, or QA team. If this is checked, we make sure to set up a mob testing session ahead of time, giving advance notice for those stakeholders who have busy schedules and may otherwise not be able to attend.
While getting mob testing correct is something we are still experimenting with, it’s had a noticeable impact on how we test things at Storyblocks, allowing us to get higher quality products out quicker with less stress and happier teams.
Additional Links on Mob Testing & Mob Programming:
https://www.ministryoftesting.com/dojo/lessons/mob-testing-an-introduction-experience-report
