Developer to Tester Ratio

As a QA manager you will need a ballpark figure for how many QA employees

As a QA manager you will need a ballpark figure for how many QA employees you want in your department. You are going to have to make a budget and fight a bit back and forth with your manager and the financial department, so you need be prepared with some arguments for what that number should be.

All of these considerations lead up to you making a goal ratio. It is a gut feeling approach you will need in the beginning and as your department materializes you can adjust to reality, but you need this goal in the beginning. I’ll go through some of the factors in this judgement.

Legacy

The difference between an old application with lots of integration points, working functionality and technical debt vs. a brand new start-up with a fully TDD’ed codebase is big when it comes to the necessity for QA.

A QA working on a legacy system will always have to sanity check older parts of the system; new functionality is likely to have new integration points with legacy functions and the developers are often touching code which was originally written by someone else. All of these factors call for more QA time on the system compared to a new codebase.

Testability

Are you looking at a monster monolith which requires a farm of 15 servers in different roles, or is it a desktop application you can install by copying a folder to the harddrive? Is the codebase modular with abstraction layers and unittest in mind?

The deployment issue is important, because the more you have to do to actually get to test a new build, the more time is used by QA to just get it running and the longer you have between iterations of builds. If you on the other hand can just pick up the output folder from your buildsystem and run the app, you can very rapidly test any features or bugfixes the developers may have.

If the developers are having lots of unittests in place, chances are you have a more modularized application. At least you will know that there are good opportunities for adding QA automation to the testing effort, which should change the composition of your team.

Automation

How much of the regression testing effort can you push to automation? And how big an effort will you have to put into it before you reap the benefits?

It ties into the testability mentioned above and forces you to think more in terms of composition rather than number of employees. That is, however, a good idea to think about before you go into the debate with the financial guys about your budget, so they see you have put more thought into the subject than just a number.

In second part of this post, I will go through more factors and show the difference between the Unity and Scanjour ratios I used.