I'm trying to convince management that testing/QA takes considerably longer than non-developers think. Some smaller shops don't have budgets for testers and phbs automatically assume the developer will spend a few minutes after every build "testing" and deliver a perfectly functional system.

Can someone point me to some numbers? e.g. Testing should be XX% of your total man hour count , etc etc? Or perhaps some real world experience? My goal is to have some numbers that are grounded in real life so I can make time/effort allocation justifications for "proper" testing when preparing estimates and timelines for applications. Maybe not full blown 100% TDD, but pragmatically close to it.

I apologize if I seem vague.

  • 1
    I suggest you to tell your boss you are the expert and they hired you because of that. You don't have to justify yourself. If they question such basic concepts, this may be a good indication that it's time to either fight hard or quit
    – user2567
    Jan 14, 2011 at 22:29
  • 2
    As the "expert", I'm supposed to give them an idea how much time testing should take so I can budget for QA staff and additional testers if needed.
    – NoCarrier
    Jan 14, 2011 at 23:23

4 Answers 4


I don't think testing can be measured in % of total time spent. If you are using a testing phase, you can always define that phase as being 10%, but it makes no sense since testing at the end is bound to find loads of problems which needs to be fixed and then you have to restart the test phase again.

A better way to approach this is to point to the fact that finding bugs early is much more cost-effective then finding them late. Read Rothmans article about it. Here is a chart which gives some more info:

alt text

As I see it testing is an integrated part of development, just as design, coding, integration is. Maybe it is easier to convince them to start working more with automated tests and integrate testing more into the development process?

  • 1
    +1 for "integrated part of development" - QA is far too often an afterthought by management when it comes to the PLC
    – bedwyr
    Jan 15, 2011 at 6:25

Some smaller shops don't have budgets for testers and phbs automatically assume the developer will spend a few minutes after every build "testing" and deliver a perfectly functional system.

If your a developer, you better take some time to test it. Anyone who doesn't should think about finding another career.

Testing should be XX% of your total man hour count , etc etc?

There is no real easy way to forecast X QA hours based on development. There are too many variables. Quality of the developers, testers etc. You also have to factor in the complexity of the code, and what it's purpose is (You would want to put a cap on the number of hours on testing say the 911 code used to track emergencies).

Your best bet is to ask the QA people how long it will take based on what it being developed. They are going to have the best estimate, as they are the ones who done the work before. If management isn't going to listen to them, then you have some real problems. What they have to decide is what is most important to them. Time spent, or quality. That is what it comes down to.

What you can do is do some short "runs". Have development spend a little time developing a piece and send it to QA. See how long each takes and start to use it as a base to forecast. (Think velocity in Agile).

  • the problem is there ARE NO QA people. I'm trying to get budget to create a QA group that is seperate from the developers.
    – NoCarrier
    Jan 14, 2011 at 23:14
  • Then that's really a different question to the one you originally asked.
    – testerab
    Jan 30, 2011 at 16:17

If you are referring to your own testing efforts, just include testing time in your development time estimates.

This should be understood by everyone, since it takes time to develop unit tests and integration tests. If management is unsympathetic to that point of view, simply explain that each time automated tests are run for a build, countless man hours are saved that would have been spent doing manual testing.

If you are a developer, how much time management spends on QA testing is really not your problem. If they don't spend enough time, that just means you need more time to make sure your own tests are solid.

All that said, it is not uncommon to spend as much (or more) time on the testing effort than the time spent doing actual coding.


The fact that they are asking for this sort of metric separately from their own historical figures demonstrates that whatever answer you give is going to be wrong.

How much time you need to dedicate depends entirely on what catching the bugs is actually worth. I have worked places where whole user bases could switch between current and beta versions at will, and their work was pretty much quick atomic transactions. That product had almost no value in QA testing beyond the validation that the data entered was stored as entered. I have also, at the same place, worked on things that could cost hundreds of dollars a minute if they were broken so we tested that until we couldn't think of anything else to throw at it.

Without context of what the risk is and what the complexity is you aren't going to have any idea of what your testing looks like, and if you don't know what your testing is going to look like you cannot come up with a reasonable metric for duration.

I understand that you are just trying to make a staffing estimate, but a generic number that does not take into account the types of products and their complexities is going to do you more harm than good IMHO.

Not the answer you're looking for? Browse other questions tagged or ask your own question.