views:

261

answers:

7

Say suppose 10 developers have taken 6 months to develop some application. As a project manager how much time should I spare in my plans for testing?

6 months of effort includes unit testing. I am specific about functional test and user acceptance test.

Is there any ratio or relationship between development time and testing time?

+4  A: 

Is there any ratio or relationship between development time and testing time?

No, there's really not. You have to look at the functional requirements of your application to determine what needs tested and how long it's going to take.

Bill the Lizard
And how much rework will be required. If you expect a lot of rework, you'd best plan for a lot of testing.
S.Lott
+1  A: 

A general rule of thumb is that testing will take 1/3 as long as development to do properly, but it can vary greatly depending on what you're doing and how extensive testing you expect.

tloach
can you site a reference for the 1/3 rule of thumb
Eric Weilnau
+1  A: 

I don't believe that is a question we can answer for you. To give you a reasonable estimate, we'd need to know several things:

What are your testing goals? (Code coverage, defects found/fixed, requirements tested, etc.)
How much time have you spent testing on similar projects?
What quality issues did you encounter on those projects? (Too many defects discovered, severity of defects acceptable/unacceptable)
Have you done any test planning yet?
How many defects did the unit testing uncover? Were there areas of greater/lesser concern? How did you address those?
What kind of test analysis will you be doing?

There are metrics that you could use to help give you a rough estimate for this kind of work, but the problem is that they really need to be tuned to your environment to give meaningful estimates. One measure might suggest 2 months for testing, but you might not realize that your environment requires twice that time until you commit to 2 months and find out that you really needed 4.

Dave DuPlantis
+6  A: 

Here is a short article from Alan Page, Test Architect on Microsoft's Engineering Excellence team :

Some examples of things to consider in test estimation are:

  • Historical data - At the very least, you can estimate test design based on previous projects
  • Complexity - Complexity relates directly to testability. Simple applications can be tested more quickly than complex programs
  • Business goals - Is the application a prototype or demonstration application? Or, is it flight control software for a spaceship? The business goals influence the breadth and depth of the testing effort
  • Conformance / Compliance - If the application must conform to a standard, these requirements must be considered when estimating the testing task.
Pascal Paradis
A: 

It's hard to answer such question. It most probably depends on your experience in similar projects. I just can provide you with some statistics for some projects I have worked in. You can see that it's hard to get a formula for the testing time in terms of the development time:

Project | Complexity | Development Time | Test Time | # Developers | # Testers


A | 4 | 90 Days | 60 Days | 4 | 1

B | 1 | 60 Days | 30 Days | 2 | 1

C | 5 | 90 Days | 120 Days | 4 | 1

D | 2 | 15 Days | 7 Days | 2 | 2

E | 3 | 120 Days| 90 Days | 2 | 2

mnour
+2  A: 

I hope that you, as a project manager, plan to use an iterative development process like Scrum or some other agile method. I wouldn't think of the testing as a phase in the development that should be done after the development phase is finished, but as an essential part of the development process.

Unit tests are great and should be obligatory everywhere, but don't make the mistake of starting too late with the functional testing. If the project is as short as 6 months it's essential to have something up and running in half that time, even if it lacks most of the functionality, and start with that part of the testing while the rest of the features are being added.

Claes Mogren
Agile is great, but regression is still necessary after development is done to ensure that none of the fancy new features at the end of development broke the boring old features from the beginning of development. And automated testing can't catch *everything* in most fields.
tloach
True, and don't forget about retrospectives!
Claes Mogren
A: 

I agree with the accepted answer from Pascal Paradis.

In addition, make sure you include test planning in your schedule. Planning can take just as long as actual testing, if not longer. This can be difficult because it requires finalized documentation from development team.

Dodi