I am working as a software developer and I had a quarrel today with our QA team about the following:
How much the QA team members should exceed the number of developers that are working on the same product?
I know that this is not a question about how to program something, but I think that this question is pretty much connected to the software development. So I hope that this question will not be closed. Instead I will get answers from professional programmers that have a good experience on working in SW developing companies so that I could make a good statistics.
Answer
The answer is very subjective, but here is my experience.
At Microsoft we have a strong test development organization. That's a little different than traditional QA because we hire programmers to test and involve them in the process as early as the design phase. Their job is to test and especially to automate the testing for the product. In my experience, it takes the tester approximately as long to test and automate a feature as it does the developer to code and fix bugs in the product. That implies a 1:1 mapping. This is very similar to the rule of thumb that writing unit tests takes about as long as writing the code.
This mix will vary depending on several criteria:
- How much unit testing the developers are doing. The more they do, the less test needs to do.
- How much the developers are writing from scratch versus leveraging existing libraries. If there is a lot of pre-existing code in use and the testers need to verify that functionality as well, that sunk development cost must be taken into account for the 1:1 mapping.
- How dynamic the development is. If you are writing a UI where relatively small developer tweaks cause a large change to the testable surface, you will need more testers invovled.
- How mission critical the feature is. To write something like GMail where it is used casually and bugs can be tolerated and fixed in the field, fewer testers are needed. At the other extreme, if you are working on medical imaging devices, you need a lot more testing because bugs are hard to fix in the field and very bad when they happen.