I often find myself having the same frustration conversation about test resources, often with different people, but sadly sometimes with the same person.
If you are a seasoned tester, I’m sure you have come across this situation before. You and your team started test execution and a few weeks into execution mass panic hits project members and everyone tries to offer a solution on how to improve the ‘efficiency’ of test execution.
Although most people have the best of intentions, the constant ‘are we there yet’ question is not really helpful.
Far too often development gets delayed and testing gets squeezed as the delivery date remains unchanged. I find the closer we are to the finishing line, the more people try to ask if they can do anything to help getting testing over the line. That is when the question ‘can we add more testers’ to help execution starts getting asked.
I find this like of questioning troublesome and there are a number of fallacies that need to be addressed when answering such questions. I’ll address two in this post:
FALLACY #1 – ANYONE CAN TEST
A person who asks this type of question often does not have the slightest understanding of what testing is really about. They have this idea that ‘anyone can test’ and that testing is just a matter of following a set of steps – hence the more people we add to the execution phase the better right? Wrong! Oh so wrong.
I’m not going to get into the argument that good testing is so much more than following a set of steps, as I believe this topic has been covered in depth in the blogs of several prolific testers and industry leaders. All thinking testers agree that this is not the case, that testing is in fact an intellectual process, instead of a mechanical, repetitive one. However the ‘anyone can test’ theory is not the only issue with the ‘lets add more testers’ proposal.
FALLACY #2 – MORE IS ALWAYS MORE
There is a fundamental principal in economics called the law of diminishing returns. In a nutshell, it states that at first, by adding more people to any given task will increase productivity, however (all else being equal) it will get to a point when the more people added to the task the less productive the task will be.
“Consider a factory that employs laborers to produce its product. If all other factors of production remain constant, at some point each additional laborer will provide less output than the previous laborer. At this point, each additional employee provides less and less return. If new employees are constantly added, the plant will eventually become so crowded that additional workers actually decrease the efficiency of the other workers, decreasing the production of the factory.”
The concept is quite simple and in testing it manifests itself in many different ways:
Experienced testers become trainers – and are taken away from hands-on testing as new testers are added to the team. The productivity of these highly important team members is impacted, affecting the productivity of the entire team.
Duplication of effort – for example, when too many testers are testing the same functionality, the same defect could be raised more than once. Or if an area of the system is blocked due to a defect, many testers are impacted.
Surrogate testers – another problem is that often these ‘testers’ are not testers at all. They are other project members (business analysts, developers) pulled out of their own day-jobs to execute a set of test cases. Some of these team members have no interest in becoming a tester, and therefore do not have the mindset necessary to conduct good testing, which brings me back to the anyone can test fallacy. It is sort of a cycle.
There are however, some instances where more testers will improve throughput and productivity of the test team. As with anything in testing the right answer will depend on the context of the project and the team. After analysing my team’s structure and the project’s status if adding more testers will be more of a hinderance than a help, I often use the arguments above to initiate discussions.
Road Less Tested 