How to Find the Right Quantity of Developers and QA Testers in Team
QA Testers and developers can be friends, in theory. Yes, friendship between a tester and developer is possible; but only if he works in another company.
After a recent conversation between a tester and a developer an idea for an article was hatched. They discussed the necessary number of testers on the team. They hadn’t considered the option where the team doesn’t have any testers at all, because one is an solid developer (and understands that a code without bugs doesn’t exist outside of fantasy), and the other guy was a tester (and knows that the code can’t be written without bugs).
The necessary amount, meaning the cosmic magical number of testers, when the speed of work doesn’t suffer and none of the testers will goof off. Of course testers may be recruited with all possible finances (even if you do not need so many), but after all, care customer care also includes financial management.
So, how many testers are needed for team of 5 developers?
From his experience, he suggested the number is 3. He happened to work in one project, where the customer experimented with the quantity of testers. There were 5/5, 5/2 and 5/3 ratios. The most productive was the ratio of 5/3, in case that no more than 1 tester is on vacation.
Of course, he wasn’t saying that 5/3 is a one size fits all solution. The ratio can be influenced by various factors, such as the project budget, project duration, product quality, implementation phase and product lifetime. If a certain number of testers has been put in the budget, then you can’t take more. Or if the terms require the release of the product in a week, the number of testers will be chosen to keep the speed of work at the required level.
Let’s put under the microscope 3 steps
The requested quality of the product.
Let’s talk about the price of a mistake and about the possibility to fix it in future releases.
Every customer wants to get a high-quality product. For example, we’re working on an app for drafting a schedule of school classes. Unimportant bugs found by target audience are fixed in one of the hotfixes, so no critical situation occurs. In this case, the ratio of the developer to the tester as 5/2 was completely might take place; also it would be nice to have the development unit tests. However if errors found in production have critical consequences (medical or banking programs), the ratio of 5/5 is fully justified (here the developer unit tests are a must). With this ratio of the team, testing one functionality of the program by different testers (for example, at the explorer testing and testing stage after assembly) is good practice. Also, complex products testing teams should include testers with different skills (performance testing, usability testing, security testing, etc.). All this allows to improve the quality and stability of the final product.
The most common strategy is changing the number of testers in the project at different phases of product development, from 5/1 to 5/5. Basically, testers are added when it’s super necessary.
How it works: There is a QA lead and one tester at the initial stage of product development. In the middle of the project, when testers get things done or the project’s scope changes, another tester is added. Before the very release, when it’s necessary to make a regression of everything that was coded in a year in a short time, the team is recruited with one or two more.
Sounds logical. But in reality, testers that were added in the last stages of product development aren’t that effective. It’s time consuming to introduce a person into the essence of the project, which is done from half a year and longer. That’s why from all the amount of work, the new tester can proceed only to the execution of already written formal tests. Giving to the new tester the task of testing new functionality is unproductive and risky. The only exception is when testers come up with experience in a similar field, but the cost of contracting such specialists is roughly equivalent to the cost of the regular tester for the entire product development path. So the question of money saving on introducing the tester at different stages of the project is truly up for debate
It’s like trying to answer the question, which is better, to nurture (to train?) your professional or subcontract it. Each option has its own diehard supporters.
The length of product life cycle and frequency of updates
The product is already released, and all the small changes that periodically come out are easily covered by one tester in a ratio of 5/1 or even more.
Unlike the previous paragraph, here the number of testers does not increase, if necessary, managers may start testing. An example would be a a long-lived online store or a start-up. At first the official tester is involved in testing the newly created functionality, and then in regression (areas that might be affected). In any case, a tester is needed, because no one will be able to keep track of whether something has broken down from the previous releases.
Also, the product might be made in one company, and is given for testing (perhaps additional or specific) to another company. Depending on the complexity of the product and the time allotted for testing, the task can be covered by one tester.
In any case, testing is a necessary stage of development of any product. While calculating the budget for testing, it’s important not to forget the well-known scheme Speed-Cost-Quality.
When you ask 2 testers to keep up with product testing in a week, when testing requires 4 testers and 2 weeks, you risk the overall quality of the product. To test the product at the required level of quality takes a long period of time for 2 testers, and in the modern world, time is the main figure of merit of the product’s competitiveness in the market.