Developers: testers ratio – testing estimation.
Submitted by Ainars Galvans on Fri, 23/02/2007 - 10:53.
general software testing | perspectives
There are two things that I (subjectively) see bad about the topic: 1) when manager assume that test estimation could be done based on developers : testers ratio 2) when a tester or test lead don’t understand why the Manager is so concerned about this ratio or even see it as Manager’s lack of understanding of testing process. You could find a lot against 1), this post is against 2). Just as with any statistics developer to tester ratio is useful statistic to be gather and kept track of but only if it is not used the primary or the only aspect for either planning or post project review..
The original intro
Note: I added the text above after comment by Jake Break. See the original intro and content of this message below.
Two of the frequently asked questions is how to estimate testing based on development estimation and/or what should be the developer: tester ratio.
Although the ratio is most attacked estimation approach and I don’t recommend to takes this as base estimation, I still want to attack those who attack the idea of considering the ratio. Do you know the term ROI (return of investment)?. If we look at testing as support task, the D:T ratio is proportional to I, isn’t it? There are no direct R however, we got paid for D work...
What does the ratio means?
Testing is support task. Project invests time and money into testing directly and indirectly. They have to pay for testing hours and for developer hours spending in transfer of information to testers, solving their environment/configuration issues, and more. You are probably lucky to be able to say “based on we will need X testers on that project and I don’t care how much developers there are and how big the project team is”. As far as I know IT industry was so lucky some 10 years ago to say to company – IT solution will cost you this much and you should afford it because you can’t live without an IT solution. Things changes and now we – IT have to prove the ROI: return o investment for implementing IT solution. Show that they will have less manual work and save money on personnel or something. Those ROI things are tricky in and so they are in testing. But one thing I could tell you – I do care and I do care a lot what is the developer to tester cost ratio on the project, because this shows me how much project is investing into testing – into having us – testers in project. They are supporting our profession and don’t be naive, they don’t want us because they believe in better quality and in better life. We are an investment only – investment to ensure UAT runs smoothly and we got paid for the project.
You could test more or test less – the result will be a more or less complete list of defect for developers to fix. They don’t want to fix everything, only enough to pass the UAT, don’t they? Or in other cases to accord to some regulations or something. That’s not project’s or company altruism that cause tester profession to be established and well (more or less) paid.
Case story: my project (context where it fit)
I'm proponent of context-driven school as I've mentioned before. So I'll give you context-driven example: the real example from real life.
When I plan testing for project that have a stable development team but the scope of the project is not so clear I do say to my manager I will need one more tester to do that project, although I don’t know the scope of testing and even the detailed scope of a development. I do know however on an average how much code that development team is capable to produce, how much bugs they will introduce along the way. Although I don’t know features in detail I know architecture/design so I know how testable will this be. And I know quality goals from management.
I mean I never compare head count. Tester just as developer performance may vary from person to person, depending on their skills, experience, etc. I’ve experienced one tester doing even better work alone when replaced team of 3 testers. More over - there are specialization. So when I say I need one more test it is not based on fact that I have 5 of them already, it is based on fact that I have those 5. And I say I need one more with skills, e.g. I need U.I. tester preferably with a business knowledge, or I need one with development knowledge.
The original intro
Note: I added the text above after comment by Jake Break. See the original intro and content of this message below.
Two of the frequently asked questions is how to estimate testing based on development estimation and/or what should be the developer: tester ratio.
Although the ratio is most attacked estimation approach and I don’t recommend to takes this as base estimation, I still want to attack those who attack the idea of considering the ratio. Do you know the term ROI (return of investment)?. If we look at testing as support task, the D:T ratio is proportional to I, isn’t it? There are no direct R however, we got paid for D work...
What does the ratio means?
Testing is support task. Project invests time and money into testing directly and indirectly. They have to pay for testing hours and for developer hours spending in transfer of information to testers, solving their environment/configuration issues, and more. You are probably lucky to be able to say “based on we will need X testers on that project and I don’t care how much developers there are and how big the project team is”. As far as I know IT industry was so lucky some 10 years ago to say to company – IT solution will cost you this much and you should afford it because you can’t live without an IT solution. Things changes and now we – IT have to prove the ROI: return o investment for implementing IT solution. Show that they will have less manual work and save money on personnel or something. Those ROI things are tricky in and so they are in testing. But one thing I could tell you – I do care and I do care a lot what is the developer to tester cost ratio on the project, because this shows me how much project is investing into testing – into having us – testers in project. They are supporting our profession and don’t be naive, they don’t want us because they believe in better quality and in better life. We are an investment only – investment to ensure UAT runs smoothly and we got paid for the project.
You could test more or test less – the result will be a more or less complete list of defect for developers to fix. They don’t want to fix everything, only enough to pass the UAT, don’t they? Or in other cases to accord to some regulations or something. That’s not project’s or company altruism that cause tester profession to be established and well (more or less) paid.
Case story: my project (context where it fit)
I'm proponent of context-driven school as I've mentioned before. So I'll give you context-driven example: the real example from real life.
When I plan testing for project that have a stable development team but the scope of the project is not so clear I do say to my manager I will need one more tester to do that project, although I don’t know the scope of testing and even the detailed scope of a development. I do know however on an average how much code that development team is capable to produce, how much bugs they will introduce along the way. Although I don’t know features in detail I know architecture/design so I know how testable will this be. And I know quality goals from management.
I mean I never compare head count. Tester just as developer performance may vary from person to person, depending on their skills, experience, etc. I’ve experienced one tester doing even better work alone when replaced team of 3 testers. More over - there are specialization. So when I say I need one more test it is not based on fact that I have 5 of them already, it is based on fact that I have those 5. And I say I need one more with skills, e.g. I need U.I. tester preferably with a business knowledge, or I need one with development knowledge.