Risks of establishing a testing team

This is an English translation of a memo I wrote in Italian.

One strategic decision I often encounter is the establishment of a group of people (I hesitate to call it a “team,” which has a very precise connotation and considerable implications) dedicated to the testing function.

Even if motivated by good reasons, is this really a sensible decision? Have all its possible negative consequences and ways to counter them been considered? Often the answer is “NO.” 

The reasons for establishing such a group (often called “Quality Assurance”) are varied.

Some are related to economic and administrative aspects: for consistency with the activities to which the QA group is called to perform, it is convenient to centralize the training of testers and career development on different levels of specialization. It is also more convenient to manage the organization of work among people, the procurement of appropriate tools, the co-presence of people in one or a few offices, the dissemination of good practices and experiences. If all these things fall under one organizational unit within the company, it will be easier to manage it, allocate a budget, monitor its operation and efficiency, and evolve and improve it.

The other big motivation comes from the expectation that it is better to assign the tester function to people who are not directly involved in building what is being tested. I call this the principle of “in a mother’s eyes, no child is ugly.” 

Even the name “Quality Assurance” is a misnomer, as it imaginatively evokes that this is the group that creates the necessary quality and, through some magic, injects it into the system being developed.

Regardless of the reasons, as a manager and business strategist however, I cannot avoid weighing the negative consequences of such a choice. And for those that I am able to imagine, I have to ask myself how the negative effects can be mitigated.

Negative consequences include the following ones.

By creating the QA group we create a silo, and as I have discussed elsewhere, we need to understand what interactions and exchanges this new group should be able to perform.

Consider the relationship with the development group and the analysis group that frequently arises. QA will take possession of a new artifact (a module, a component, a subsystem, a release candidate of the whole system) released by the development group and carry out the testing procedures it deems appropriate. Upon completion, it will produce feedback that will be communicated to the developers, in the form of a report. In deciding what test procedures to implement, QA will have interacted with the analysts and designers, who will have had a written formulation of requirements and technical specifications provided to them. In this scenario a whole series of “stumbles” typically take place that make it far from a “lean production” perspective, which is centered instead on avoiding waste and maximizing value.

Meanwhile, there is delay with which feedback is communicated from QA to developers. In addition, communicating such feedback via a report degrades its information, fostering misunderstandings and errors, which leads to further delays and repeated activities. 

Interactions between analysts and testers also suffer from the same type of problem.

It also encourages lack of responsibility, even in good faith, on the part of developers. Assuming that QA colleagues anyway do careful quality assessment work, in times of crisis and emergency, developers will be comfortable thinking thus “…I think there are no serious defects. I’ll release in the meantime. However, there is QA that if something comes up will find out.” 

But it gets worse: by imagining essentially unidirectional communication channels (analysts to QA, QA to developers) and excluding channels between QA and the Product Management group, many opportunities and strategic goals that testing can offer are wasted.

In fact, with close contact between QA and developers, practices such as Test Driven Development or Behavior Driven Development can be implemented, which leverage testing to guide developers in their work and make them more productive and create a product with more focused features. 

With close contact between analysts and QA, testers can review and help improve technical specifications before developers start working on them. Thus preventing those errors and gaps from propagating and consuming valuable resources and time. In addition, testers will have more information regarding the why of various technical specifications and even requirements, which will enable them to put in place more effective testing procedures.

With direct QA involvement with product management, practices such as BDD can also help to understand what the strategic benefits of a product may be and how that product can hope to achieve appropriate business objectives.

With frequent interactions between QA, Product Management, analysts and developers, very effective quality risk analysis initiatives can take place, leading to better testing procedures.

So, to summarize, the negative consequences of naively introducing an isolated QA team are:

1. longer cycle time;
2. compression of testing to the final stages of a release, resulting in reduced effectiveness;
3. low confidence in the level of quality achieved, and thus difficulty in project management;
4. higher costs to deliver, and higher costs to manage the low quality of the release once it goes into production. 

And the question then becomes, “Are these costs balanced by the benefits associated with the reasons for introducing into the QA group?” Generally no, at least if we evaluate them based on the economics of the company, not by the individual manager. 

The real benefit that a QA group brings (and even better if a QA team is formed) is related to the problem of the mother’s eyes and specialization.

So the winning trick is to establish the testing team, but make it permeable to frequent and rich interactions with developers, analysts, and product managers. Only then it does not become an isolated silo that hinders and makes “lean testing” impossible. Appropriate mechanisms must be put in place to reduce possible lack of responsibility.

In a future post we will see how this type of problem was addressed in a context with several dozen agile teams.

Pubblicato originariamente come Articolo LinkedIn.