Whole Team Approach to Testing
Most of the software teams have gone AGILE, but are we really following the principles of agile when it comes to quality & testing? In my personal experience, the answer is NO. We say we are an agile team, but when it comes to quality, the entire responsibility, by default, goes to the QA. We actually forget that agile endorses the WHOLE TEAM APPROACH.
What is “WHOLE TEAM APPROACH”?
The whole-team approach, also called the team-based approach, is a project management style in which every team member on the project team is equally responsible for the quality and success of the project.
Janet Gregory and Lisa Crispin, in their famous book “Agile Testing”, have described the whole team approach as one of the biggest differences in agile development as compared to traditional development. In simple words, a whole-team approach means involving everyone with different knowledge and skills to ensure project success. Same applies to agile testing as well. In agile projects, testers are not Gate Keepers. Instead, testing is a shared responsibility and should be done by all members of the agile team. Each team member can do testing in different ways and at different levels.
Benefits of whole team approach in a team:
Now, when we say that testing should be done by all team members, we can’t ignore the fact that most likely there will be some pushback, they will not want to take responsibility for a thing which is not their primary job. But, the key point to understand here is that they need to have an understanding of what skilled testing is so that they can utilise that knowledge in an hour of need. Example: the only tester in a team is out sick or has some emergency. This is not all, there are other advantages, too. It is common to have a lot of back-and-forth between devs and testers for fixing a ticket, in teams where a tester is only responsible for testing. This back and forth, actually wastes a lot of time and can be avoided if the whole team will have a quality mindset.
For the whole team approach to work, sharing knowledge with the team is a must. There is no denying that everyone’s perspective is different and the entire team will not be expert in testing. But in agile, it is always better to have cross functional teams. Through knowledge sharing, we need to actually mentor the team to view the product from a different viewpoint.
There can be different methods to share knowledge, depending on how your team is, the environment and culture and what works best for you. Do not hesitate to try different options, before you find the best one for your team. Below I have listed some of my favourite practices:
1. Documentation:
Technical documentation in an engineering team includes all written documents created through the whole software development lifecycle. There are few documents specific to testing also like the test plans, test cases, requirement documents etc. It is always a good idea to document and store all useful documentation at a central place. This documentation can be one of the methods to share knowledge with the team.
2. Knowledge Sharing Sessions:
These sessions are intended to share your learnings, and can be scheduled once a week/month as needed. A small demo or hands on can also be included in such sessions to better coach your audience. An important practice here is to record these sessions and store them, so that these can also be used when a new member joins the team.
3. Pair Up:
Pairing is a very collaborative way of working and involves a lot of communication. It is a technique where two people pair up to complete a task. A very practical example of this approach is — A developer and a tester pairing up to write automation tests. This approach can also be used to perform exploratory testing on a feature (where a developer and tester can form a pair). There can be different styles of pairing like strong style, traditional style & remote pairing.
4. Mob Approach:
Mob Testing is about a group of people testing the same thing, at the same time and on the same computer. This is a very interesting way of doing testing, and as every individual has different viewpoints and perceptions, it brings out the best out of everybody. If you want to know more about this, read it here.
There can be many other ways to share knowledge, what method you use, is entirely dependent on your context.
Conclusion:
The Whole Team Approach is an important step forward in software projects. How you take this step and what methods you use entirely depends on what problem you want to solve. Any blog, book or course can just give you inspiration or the ways that you can try, but in order to find out what works best for you — give things a real try. Only if you try things out, in your context, you’ll know whether they work or not.
Thanks for reading and please leave your comments/feedback below, if any 🙂
Follow me on:
Connect with me on LinkedIn (click here)
