A state of the art of software testing teams
Agile has turned traditional development methods on their head, and with them team structures and the expectations of the various stakeholders.
These multiple changes have many positive and negative impacts, which are as much due to the agile philosophy as to its operational peculiarities linked to the V-cycle. Testing and testers are therefore impacted.
From the positive impacts, the ease of testing earlier, taking it into account and integrating it into teams are concrete examples. But don't overlook the generated constraints!
Constraints and negative impacts of Agile on software testers
There are two main reasons for this:
- The tester is often the only member of the team, and is generally considered to be the test and quality referent.
- The team expects a great deal of skill and knowledge from the tester, in order to rely on him in the same way as with the V-cycle testing team.
These constraints lead testers to the negative impacts of switching to agile methodologies. I'm thinking in particular of:
- A demand for experienced testers on the team
An agile tester has to be able to solve a lot of problems while spreading the quality spirit throughout the team. To achieve this, the team expects him to have a strong background in testing, as he not only has to know how to apply, but also how to adapt and make people understand!
It's hardly surprising, then, that “junior” testers find it hard to find assignments in these teams.
- The need for testers to master many aspects of the business
A tester on an Agile team needs to have a wide range of skills. He or she is a “jack-of-all-trades”, and should ideally have a good grasp of many subjects, such as: automation, BDD, API testing, test design, virtualization of environments, management of continuous integration chains… It's not a coincidence that all these subjects are included in the Agile technical tester certification.
- A potential sense of isolation for the software tester
This is a very important point. A tester in an Agile team is often alone. This makes it potentially complex for them to exchange ideas with their peers, to benefit from their experience in solving problems, and to avoid having to reinvent the wheel. This feeling of isolation can also encourage staff turnover.
In general, these problems are much less acute in a V-cycle, with teams of testers. Automation, design, and planning skills are shared between several people. Juniors learn from experienced testers, and exchanges between peers are simplified.
Does it mean that switching to Agile means giving up these V-cycle strengths? Fortunately, no! It is of course possible to set up the equivalent of a test team in agile environments.
Software Testing teams in Agile
1. The benefits of an Agile software testing team
The notion of test teams resonates strongly with the V-cycle concept. Nevertheless, they have demonstrated their capabilities and their value. Their absence also demonstrates, in many agile contexts, that there is a real need for a team, a sense of belonging and the ability to exchange with peers.
The real question is not whether to set up Agile test teams, but how to do it in environments and/or companies with a certain number of testers.
Don't worry, there are many possible shapes, and it's obviously necessary to determine the one that best suits your context. The first step, as with any set-up, is to identify your goals.
Among these common goals, it's relevant to quote:
- Standardizing practices (especially in agile at scale)
- Limiting turn-over
- Enable testers to monitor and upgrade their skills
- Capitalizing on knowledge and tools
- Limit superfluous work or time wasted on problems already solved by other teams
- Optimizing testing efforts
- In Agile: Improve all testers' knowledge of the overall product
It's also a good idea to know how much “directionality” you want to offer.
2. Setting up an Agile software test team
As with any process, tool or methodology implementation, the creation of an agile test team requires preparation and adaptation to the context. Among the essential elements of this preparation, there is the criterion of the “power” of this team, also called “degree of objectivity”.
The lowest degree of objectivity can result in the creation of one (or more) “communities of practice” of testers. These communities of practice are then places where testers can easily exchange and share their knowledge.
The limitation of this approach is that it essentially relies on good will and “best effort”. It is therefore fragile and often limited in terms of capitalization and/or standardization of practices.
However, It does have a number of advantages, including great flexibility and low investment costs.
The highest degree of directionality can be expressed by the creation of a “test center”. All testers belong to the test center, which assigns them to agile teams. The test center then centralizes knowledge, practices, and tools.
One of the limits of this approach is the limitation of freedom within agile teams. Problems may also arise in terms of time spent by testers on their agile teams. Another limiting element is the structure of this center, which may require several people to manage it.
Nevertheless, this approach offers a number of advantages, such as real knowledge sharing and a significant capitalization of what is being done in the different teams. The ability to train newcomers before they are assigned to agile teams is another advantage.
Of course, it's possible to have a more measured degree of objectivity, by proposing a solution that takes the best of both approaches, or simply by creating your own solution. Personally, I've often experienced this in-between situation as part of two teams. An Agile team, but also a test team. A maximum percentage of my time was dedicated to the test team. This time was used for testers' meetings, feedback, or work on shared processes or tools. This arrangement worked particularly well in my context of Agile at scale.
Conclusion
Agile has transformed the software industry. As with any transformation, there are positives and negatives. Among the negatives of the testing profession, there is the dispersal of testers, resulting in the accumulation of knowledge without the ability to easily exchange with peers. To address the issue of skills, it is possible to offer tools that facilitate certain activities, such as Agilitest for automation. Unfortunately, tools can't solve all problems, such as those linked to isolation and limited exchanges with peers. In response to this, setting up new forms of test teams in an Agile environment is very often an effective and sustainable solution… Provided it is implemented in a way that matches the company's context. To achieve this, it's essential to strike the right balance between the directive nature of the test team (which can go by many names) and the essential freedom to be left to the agile teams.
.png)
