Estimating testing times how many QA engineers you’d need for any given project can be a tricky task. And perhaps a more important way to look at the situation is, instead of knowing how many, you’d want to know when to have the engineers come in. Shifting left – introducing QA earlier in the SDLC – is becoming the new norm too and with it the realisation that spending resources on QA and defect management tools is an old-school ideology.
With the levels of testing available today, ensuring your QA comes in earlier is important to see out the entire testing process. Ideally, you’d want to create your product development budget with the 80/20 split in mind. Estimating the 80% of resources you’ll need before starting any project is key here and so is the remaining 20%, which accounts for any unforeseen changes that may come along the way. The last thing you’d want during any project is asking for additional resources from the upper management.
Complex projects can be thought out differently though. Estimating one QA technician for every six developers is a decent ballpark to keep in mind. This is especially true if the project might take up to a year or more to develop and market. Or if it includes an extensive database or back-end communication.
QA staffing to start early in the schedule
As mentioned before, shifting left is becoming the new norm. Getting QA and defect management tools early in the developmental process is going to be essential moving forward. The more QA is involved, the better the results are going to be so allocating the final two weeks of development won’t be enough to polish the product to satisfactory levels.
We’d recommend having your QA lead attend the very first product development meeting to analyse the lifecycle process and aid as a reviewing guide. This also benefits the QA team as working closely with designers and developers can help them understand the product better. By doing this, they’ll have a better idea on how to approach the testing process and what defect management tools to use to help them achieve the best results.
The needs of the upper management need to be quantified
One of the best gauges on when to add more QA staff is knowing how overworked your current teams are. Before it gets to a point where they threaten to quit, try and anticipate future needs of your team. How do you do that?
Software developers can make about 100 to 150 errors in every 1 thousand lines of code, on average. Even if you took a conservative estimate and suggested only 10% of these errors were serious, then a small application consisting of only 20,000 lines of code can amount to 200 serious errors and defects. One way to solve this issue is to look at any projects that are of similar nature and quantify their error rates. This is where QA and its documentation can come in handy. But if working on a new project from the ground up, discreetly asking on articles and online forums can set you up for a good benchmark.
Perhaps even more important is knowing the worst-case scenarios for your end-user. Knowing how errors in your product can risk lives, livelihoods and lawsuits is an incredibly important consideration to take into account. Some of these may not be as easily answerable than others, and where applicable, ask upper management and legal teams for advice.
These two methods can help get everyone on board a general idea on what the error rate might start to look like. Once done, you can build your own algorithm. And while it does leave room for a lot of guesswork, it can help narrow down your approach significantly. In the very least, it can provide senior management with a ballpark figure to entertain.
Also read about: How Business Can Increase Revenue with QA Automation
