Independent Testing Teams in the Agile Environment | David Tzemach
Updated: Mar 3, 2022
Most of the testing effort, and in some cases all of it, is strictly the responsibility of the Agile team. They should perform all activities related to delivering high-quality solutions to their customers.
Another important aspect is the whole-team approach, which states that all team members have accountability, responsibility, and ownership for the commitments of the development cycle. However, while this is good in theory, there are just too many challenges that may prevent the team from handling all the testing aspects.
The whole-team approach is limited in specific scenarios such as scaling or a particular testing process that demands specialized knowledge and experience that do not exist in the team (e.g., performance, scale, and security testing).
Why Do We Need Independent Test Teams?
To handle these situations, there is a need to establish (or at least consider) independent test teams (yes, like in the traditional environment) that provide the second quality layer by handling some of the more challenging test activities that the regular Agile team cannot.
A necessary clarification is that the independent test teams do not replace any of the regular test activities of the regular Agile teams. In fact, their work is based on the creation of a working build that the regular Agile teams deliver in a specific period (in the middle of the sprint or sometimes even at its end).
Moreover, independent test teams are not (and should never) replace the testing process conducted by the development teams in the regular development cycles but should focus on the testing gaps that the Agile teams cannot cover.
These are some aspects that independent test teams should focus on:
Approve the overall quality of the build – Independent test teams are usually focused on non-functional testing that gives the team quick feedback about the overall quality of the build that is mainly tested on the functional side.
Validate the implementation – Independent testing teams have the power to reveal whether the team has successfully implemented the requirements or not. This is one significant advantage as it increases the overall confidence in the product and ensures that the customer gets exactly what he asked for.
Reveal any of the critical bugs missed by the teams. As part of their testing activities, independent test teams reveal many of the missed bugs in the regular development cycles.
Conducting the testing that is too difficult to manage – This is one of the main reasons to create these test teams in the first place. Independent test activities should focus on the testing aspects that regular development teams cannot handle.
Readiness testing pre-production upgrades – In many practices, the independent test team holds the responsibility for approving the system before use in the internal production environment.
Independent Test Teams as an Agile Anti-Pattern
Some purists say that the idea of independent test teams is simply an anti-pattern for what Agile development is all about. Simply yes, it may start there, but there is a big difference between theoretical aspects that looks good on paper but do not hold water in real execution and pragmatic good sense.
To determine whether to follow the purists or do what is suitable for your organization, answer the following questions:
Do your Agile teams have the knowledge and experience to handle the non-functional side of testing (e.g., performance, scale, security, usability, etc.)?
How is non-functional testing affecting your team’s ability to deliver real value to the business?
How many of the escaped bugs were supposed to be found during regular development cycles, which could be found by an independent testing process?
Do your Agile teams have the capacity to handle the effort involved in non-functional testing?
Are your teams new to Agile and still not adapted to this new development process?
Sometimes the need for an independent test team is just an essential part of the overall development cycle, especially at the start of an Agile transition. The teams are still unfamiliar with the concept and effort involved in short delivery cycles.