Management · July 11, 2022

Swarm Testing

TL;DR

Swarm testing applies swarming (mobbing) to software testing: a team meets for a 30 to 45 minute huddle to test a feature before release, using prepared test plans and Jira tickets for bugs. It complements existing QA rather than replacing it.

Introduction

Swarming also known as mobbing or huddling is now increasingly being used in software engineering. This is a process where a team or group of people agree to collectively tackle a task, resolve an issue or incident. This approach was traditionally used when a team must complete a task given a limited time. It is known to facilitate knowledge sharing and collaboration within a team.

When swarming process is applied to software testing, this is referred to as Swarm Testing. During swarm testing, a team organizes a huddle to test a feature of a software product before the eventual release. This process is not to replace but complete the existing quality assurance processes for software engineering cycle that a team might already have in place. This type of testing is effective at reducing cycle time, improving coverage and fault detection.

Swarm Testing Session

The engineer or the lead of a project is expected to consult with the team to determine if the features of the project to be tested qualifies for a swarm testing session. The project lead will identify the participants of the session and send out the meeting invites. The recommended approach is to have a mix of members that worked on the product features and those that did not.

Test plans and scenarios are to be prepared ahead and allocated to the participants. The appropriate duration of the session should be determined based on the number of test plans to be covered. It is recommended to keep the session between 30 to 45 minutes for optimal focus and participation.

Before each swarm testing session, the project lead will create the test plans and scenarios in a document or repository that is accessible to all the participants. The test plans should not contain tests already covered in the unit or end to end tests for the feature. A document or wiki page should be created using the template available later in this post. The swarm testing session document or wiki page should be filled by the project lead and shared with session attendees before the session.

During the session, the project lead will introduce the new feature by presenting the end to end flow of the most common use cases. The role of each participant in the session is to have their environment and test accounts set up if necessary. For example, some test plans require certain access or privileges, these priviledges should be requested before the session.

Any participant can create the Jira ticket for any issue or bug detected during the session. The jira ticket created should include a detailed description of what the issue is, steps to reproduce and the screenshot of the issue if applicable.

Swarm Testing Template

This template is a guideline that could be used in preparation for a swarm testing session. The template provides details about the session and guideline for participants on what to focus on during the session and where to log the outcome of the tests.

Project Details

Project:	< Link to project page >	Feature Flag:	< Feature Flag >
Date & Time:	< Date & Time >	Product & Technical Documents	< Link to Docs >
Design Assets:	< Link to Figma >	Jira Epic	< Link to Jira Epic >

Attendees

Project Lead(s):	< Link to Profile >
Team members that worked on the feature:	< Link to Profile >
Other team members:	< Link to Profile >
EM, Design & PM:	< Link to Profile >

Environment Setup
These are the requirements to be met by each participant for the session.

Tools & Access:

dev/staging/prod access
Access to Jira backlog

Test Accounts:

Brand-new account, no data
Account with some test data
Account with lots of test data

Browsers:

Google Chrome
Safari
Firefox
iOS/Android browser

Test Plans

For PM, Design & EM
Focus on design patterns and user flow

< Link to test plan >

Other team members:

< Link to test plan >

Team members that worked on the feature:

< Link to test plan >

Filing bug or issues
Participants will update this section with links to jira bug tickets, for PM to prioritize.

Jira Bug Ticket Link	Check if Blocking Release
< Link to Jira ticket created >
< Link to Jira ticket created >

Frequently asked questions

What is swarm testing?

When a team organizes a huddle to collectively test a feature of a software product before release, applying swarming (also called mobbing or huddling) to testing. It is meant to complete, not replace, the QA processes a team already has.

How long should a session be and who should attend?

The recommended length is 30 to 45 minutes for optimal focus and participation. Invite a mix of team members who worked on the feature and those who did not, plus engineering management, design and product.

How are test plans and bugs handled?

The project lead prepares test plans and scenarios in advance in a shared document or repository, excluding tests already covered by unit or end-to-end tests. Any participant can create a Jira ticket for a problem, with a description, steps to reproduce and a screenshot if applicable.