Scaling Test Teams

thought piece
a movie still from Purl 2018
Purl, 2018

There’s a question that all “schools of thought” in software testing slip and sweep under the rug. Some of them do so by:

while others

I admit, both of these are exaggerated extremes, but both are visible whenever someone asks the question

How many Testers (or Test Engineers/Technical Testers) should my team have?

Folks either promote a ready-made final solution based on their own reality or their imagination, OR they understand that the question is heavily linked to one’s context and, not knowing the context, prefer to not induce folks to error with a final solution.

I risk saying: you won’t actually find many craftsman testers worried about this question, more often than not they are on the next stage of the problem: I already know what kind of testers I need and how many of them I need for my context, but I can’t get them, either due to lack of money or other compromises in my org.

BUT, for the rest of the world, this is a question that troubles non-Testing lay-people looking desperately for an answer, some of which will resource to a solution that is faith-based, money-based, family-based, witchcraft-based, … in sum, desperate folks looking for a solution prone to complete failure and being taken advantage of.

So, what is my “look here in my pocket” kind of solution that I propose instead for these desperate people?

Well… here it goes, I propose a balance:

between a back-of-the-envelope estimation and an understanding of underlying context.

This balance is an exercise, basically an heuristic, that in the recent years I used to do mentally but never put into words. Let me make up a name for it on the fly:

A node-weighted approach to scale Software Testing and Test Engineering Teams for the benefit of smart or dumb software development environments

Patent pending. Alright, fancy words done. What is it about and how can you use it?

I’ll try to explain it all in 3 steps:

Understanding the Test function

I’ve written about Testing and its importance on other posts in the past. In order to properly scale any testing related team you have to understand what the Testing function is. There are a couple core principles that I believe are crucial to get right from the start before doing any scaling work:

Testing and Test Engineering are different faces of the same coin. You can’t shouldn’t have a coin with two heads or two tails.

From the above principle, it’s been helpful for me to keep the bellow definitions also as core principles:

I admit this is a narrow view of what these two functions are, but, the implicit and intimate understanding of these, in similar lines, is what makes or breaks someone designing and scaling a testing function in a project. Too soon some folks setup teams and start hiring for positions not understanding the actual needs of a project, the function of Test, and what Testing really is. Other people in the org are drugged with wrongful principles and definitions, and what should be a simple exercise of defining the size of the Test function in a project, becomes a hazing exercise of “who’s got the biggest “quality assurance” Willy and influential power”.

From the above three principles you sketch out everything else:

Understanding how the weight of each branch is linked with context

If you start doing a sketch of what you need versus what you might afford in different organizations you’ll soon observe a couple of points:

Let’s try to put this in a diagram:

Diagram of test function in the form of a tree, initial node being Test Commando, branching out into Tester and Test Engineer, Tester branching out into Glue work, Generalist, Domain Expert, and Test Engineer branching out into Glue work, Expert, and Tooling.
Diagram of test function in the form of a tree, initial node being Test Commando, branching out into Tester and Test Engineer, Tester branching out into Glue work, Generalist, Domain Expert, and Test Engineer branching out into Glue work, Expert, and Tooling.

Given a project of a certain scale, you’ll find yourself in the position of needing one or more of the following:

Past a certain scale, when the project needs more stability and long-term vision on the Test Function than improvising on the job:

And finally at a massive scale (which doesn’t always necessarily mean more complexity) you’ll want to branch out further into folks that:

We can mold the above to any of the common scenarios:

If you identify the different roles/parts that you would need in your context, knowing how many of each you would need is an exercise of:

And lastly, the favorite part for folks behind “the budget”: you can definitely attach a (fair, or unfair) price-point of the human-hours cost to each node of the tree, and similarly assign a weight, adapted to your hiring market and to your project’s needs. After that, the question is no longer how many folks do I need, but how many can I afford, based on the price/weight, and that is something only you are empowered to answer, no matter how many ready-made “for X number of developers you should have Y number of testing folks” answers you might have lying around from “experts”.

Usually when it comes to hiring market decisions:

As for project’s needs, if feel you are disconnected towards your org’s reality, there’s a couple of key indicators that might help:

Keeping the system clean

The final step of solving the “how to scale a Test/Test Engineering team” issue is one that is not related to pricing or attributing the right weight and focus to parts of the system, but it is a problem of keeping your Test function “lean and clean”. Too often folks try to solve the “Testing” chunk of their development process by adding to the system, but not by maintaining the system. Perhaps this is easier to explain with examples.

The gist of this being - before answering the question of “how many testers”, it’s useful to try to answer other questions like: what kind of value are we getting from our current approach, and where could we do better with the people we already have. Oftentimes, no matter how well you design your Test function, your org is restraining the Test function from doing its best work through other parts of the “development process” system being overlooked and swept under the rug.

TL;DR: If you’re not convinced, but you read this far, I have a gift. An exact dev-tester ratio that works every time, well kept by wizards of Testing: for every 5 developers, you should have 3 Testers. The logic behind this is that 8 humans are enough to feed an adult Allossaurus and a handful of Velociraptors each day, and it always scales efficiently assuming you can control your Dinosaur population, and they are all females. PS. Do not use frog DNA.

If you read this far, thank you. Feel free to reach out to me with comments, ideas, grammar errors, and suggestions via any of my social media. Until next time, stay safe, take care! If you are up for it, you can also buy me a coffee ☕