How to estimate testing time for project when development estimated time is fixed/decided?

Question

I am experienced tester. Mostly I estimate any project testing time based on requirements. But, now I have an interesting question,

for example, I have checked requirement and if the developer is saying that they will need 30 days to complete development.

So, at this stage, how should I estimate testing time? Based on given requirements? Or based on estimated development time?

I am thinking that if developer needs 30 days to develop then as a tester I need at least 1/4 time, meaning 7-8 days to complete testing. Is this a right way to estimate time required for testing a project?

Answer 1

This depends on many factors. How accurate and reliable are developer estimates? For throughout the testing needs to be? How efficient you are in testing compared to the developer? How you count the time needed for bug fixing and re-testing (and re-fixing and re-re-testing); is it development or testing time?

An old rule of thumb is to take original development estimate and multiply it by π and use that as the total time used for the feature. ;-)

Answer 2

As it has been said already, it depends but, going by development time does not tell you that much. Some guys can code a mile a minute while others are snails. Some do good unit testing while others don't do any.

My process is as follows:

1) Requirements documents. If available, I always estimate based on the requirements document. I outline my testing and estimate the areas to be tested, the number of cases and so on from this document.

Then:

2) I take into consideration past experience with the developer(s). How buggy their code has been. What has been their fix turnaround time?

3) Size of the development team vs my team.

4) Whether all code is in-house or is outside libraries used (new to us libraries).

5) How critical is this development? It is a brand new product or an add on feature (most likely your case). How many and what other systems does it touch? Basically, do we have to regress of bunch of other stuff as well?

In either case, my estimate normally starts after the code has been tested/soaked for a week or so. Many times we find critical bugs the first week, fixes for which eat into testing time. In my group, my testing time does not start until we accept the code drop, which we will do after running a series of tests, i.e. soak time.

Hope this helps.

Answer 3

As an initial guesstimate, I would equal the developers estimation.

Obviously you should adjust it to your circumstances. For example, do you need to develop automation?

If yes, do you have an infrastructure you are familiar with?

Is this a new project?

How complex is it compared to previous project you tested?

Is there any special risk regarding quality like inexperienced developers, unclear requirements, immature technology or lack of test equipment, and so on...

Answer 4

1) As a tester, you should go through the requirements for your estimation instead of going through the estimation time given by the development team.

2) From the requirements, you should estimate the time for creating/updating the test case for the given requirements and the time to execute them.

3) Also, you need to consider the scenarios like; if you are doing the web app testing, then on how many browsers you need to do the testing and if you are doing the mobile app testing then you need to consider the different OS version for the testing like; Android, iOS, Windows and BlackBerry OS (as per the clients requirements).

4) Also, do the estimation for executing the regression testing.

5) Divide the task within your testing team so that no one in your testing team sits ideal.

6) Also, consider the estimation for the Beta Testing (if you/your team are doing).

Note: As per your thinking; if the developers need 30 days to develop then as a tester I need at least 1/4 time means 7-8 days to complete testing, Is this right way to estimate testing time? >>> It depends upon the no. of testers you have in your team. If you are the only tester in your team, then it is surely going to take time. But if you have more than 1 tester in your team, then you will be able to complete the testing task in less time due to more no. of hands.

Answer 5

Having a fixed formula for estimating time for testing a project may not necessarily be the right way.

As you may have already heard the phrase, there is no one size fits all formula.

Estimations are always context based. They depend on the requirements of the project in that context and would be different for each project.

Yes, if there are any similar projects you have worked on in the past, then you can take them as reference and accordingly give estimates.

IMHO, the notation (that many follow) of allocating 20% or 25% of developement time for testing is just stupid. This also bothers me a lot because this usually ends up very bad for testers in a sense that there isn't enough time to cover the whole project. And, any leakage of bug is also then blamed on the testers instead of considering the fact that the whole team didn't care much about quality to being with and hence didn't spare sufficient time.

There are countless things to consider before you can make a guess on the time you would need to test a project. Some of them have been listed in the other answers to this question So I won't repeat them.

This article here has a nice mind-map of a few things you can consider for estimating a testing project.