Group Testing: A Key to Implementing the Whole Team Approach to Quality

Why everyone can not be responsible for testing!

The “whole team approach” is a key tenet of Agile software development. At its core, it means that everyone involved in a software delivery team is responsible for delivering high-quality software. At its best, it helps to ensure quality is built-in to a software product at every stage of the development life cycle. Despite this promise, it can be a challenge for some teams to effectively implement the whole team approach for various reasons. In this article, I highlight some of these challenges. Then propose a way they can be remedied.

The challenge:

To start with, the whole team approach concept is often misinterpreted to mean that everyone in a software delivery team is responsible for testing (rather than quality)*. In this sense, testing is viewed as an activity in the development circle that everyone can perform. Yet, there are different levels, phases, and types of testing, all of which has different objectives, and requires different types of expertise to be done effectively.

Similarly, many proponents of the whole team approach also seems to over estimate the possibilities for individual team members to multi-task. They tend to believe in the assumption that people can stretch their cognitive capabilities across multiple functional areas, at the same time, and still be effective across all. Many studies in psychology has for a long time proved this idea to not be necessarily true for most human beings.

In fact, beside the testing function, every member of a true multi-disciplinary Agile software development team would usually have designated expert areas. And to those areas they will often dedicate the most of their time and effort. Therefore, to improve testing efficiency, and perhaps improve product quality in a team, it is always a good idea to have someone or a group of people responsible for testing in a team. Especially, in an era where job responsibilities are still specified along different expert areas such as Software Engineers, Test Engineers, Business Analyst, Data Analyst, Product Managers etc.

Quality and testing defined:

I present below an understanding of quality, and of testing that I uphold to. I believe these definitions provide an encompassing understanding of product quality, and testing specifically.

* Quality: “the functional, non-functional value (in usefulness, correctness, and goodness) that a product provides to the people who it matters to, at a given point in time.”
Inspired by Dan Ashby’s conceptualization of quality characteristics. See Ashby (2019)

* Testing: a process in which you evaluate a product by learning about it through experiencing, exploring, and experimenting, which includes to some degree: questioning, study, modelling, observation, inference, etc
Bach J. (2013) and Bolton M. (2014)

So, if testing is to be understood as a process of “information gathering” about a given product, which is achieved through the interactive, cognitive, and intellectual process of engagement with the product. Then, it is perhaps misleading to believe that everyone in an agile team could effectively share the testing responsibilities. To this end, I have become convinced through my experiences in recent years that it is a misguided notion to believe that everyone in an Agile team can truly be responsible for testing. This is not against the idea that everyone in a team should be responsible for the quality of the product they develop. Rather to emphasize that being responsible for testing, and for quality are two separate things.

My perception is based on the notion: “if the responsibility for testing belongs to everyone in a team, then it belongs to no one.” Because it will always difficult for everyone to take equal ownership for the cognitive engagement needed to gather the most relevant information about a product.
/Me

Implementing the whole team approach:

Many individuals and teams interpret the whole team approach differently depending on their context. Thus, the implementation can also be different depending on the team. However, the goal is usually the same. To involve and utilize the expertise of everyone in a team for high quality software product delivery.

The question usually is:

How can you as a team, or someone responsible for testing ensure that you are maximizing the expertise of your team members to contribute to the quality of your deliveries?
And how can you effectively employ the whole team approach to enhance the quality and value of your release increments to your customers?

In recent years, I have found that one effective way to ensure everyone in my team contributes to the product testing effort ahead of releases, is to organize group testing sessions (aka mob testing).

Group testing:

A group testing session is a testing and product exploration session where every member of the team take active participation in exploring a feature/ product ahead of releases.

When I have organised group testing sessions, they are usually designed with the hypothesis that:

Given, we want to release a new feature/product to the audience,
If, we come together as a group to explore the feature/product,
Then, we can gather relevant information to aid informed decision making on its perceived quality.

Key objectives:

Exploration: exploring features from different perspectives.
Knowledge sharing: sharing knowledge about observations and the behavior of the feature or product under test.
Issue Triage: discussing observed issues/ outcomes, and agreeing on appropriate course of action.
Accountability: assigning tasks and ownership for agreed actions.
Information Gathering: gathering relevant information about the feature to aid informed decision making on its perceived quality

If you work with Agile, and you are looking for ways to involve your wider team in your testing process or enhance collaboration and knowledge sharing in your team. Then organizing a group testing session may be one way forward. To do this, the below are simple steps you can take.

Implementation format:

Plan in Doc: create a group testing plan in any shared documentation space so it is accessible to all team members.
Define groups: define groups of 2-4 people with even spread of disciplines (I.e. Software and Test Engineers, UI/ UX, Product, Delivery, Team Leads, Colleagues from other teams etc.)
Device Coverage: Each team covers relevant devices*, i.e. Android phone, tablet, kindle etc. for an Android app related session. or iPhone, iPad, etc for iOS app related session, etc.
Define Focus area: each team starts from a given focus area, then move to other areas to allow spread in functional coverage.
Schedule: 30 – 45 mins team sessions, 1 hour -1:30 hours session with the larger group to review, discuss, decide, and assign tasks.

*Relevant devices: suffix with whatever test device that is relevant to your context.

Outcome:

The result we gain, which you can also expect from following the above listed steps to carrying out a group testing session will usually include, albeit not limited to:

Review: We review the observations from each team.
Discuss: We discuss the standout observations and their implications.
Prioritize: We prioritize and decide on the appropriate course of actions for the observations.
Assign: We assign tasks for who takes ownership for the items discussed, and agree a timeline for fixing them.
Fix: We fix the prioritized items according to agreed schedule.

The outcome of these sessions has always been considered very useful in my teams. I believe that by employ this collaborative approach to testing and quality improvement, a team can redefine and successfully implement a version of the Agile whole team approach. It will be practical, fun, collaborative, and it will produce results that exceeds the expectation of what a single person can contribute to the team from a testing and quality perspective. what approach to team

Final thoughts:

I believe group testing is a valuable idea to build into the whole team approach to Agile software development and testing.

Throughout my experience, I have always found value in doing group, and I believe it is an idea many teams can benefit from. If it is not something you already have built into your process, then I highly recommend you give it a try, and see if you find it useful.

If you or your team need any help implementing the ideas described above, do not hesitate to reach out.