5 Simple Steps of Software Test Estimation

Posted on Dec 14 2012 - 5:05am by Raj





New here? Like us on Facebook to stay updated of new posts. Plus, if you think your friends or followers will enjoy this post, please share on Facebook or Twitter using the buttons above.

For Effort estimation in testing there can be various approaches. In this article, we will discuss some of the basic steps you always need to follow.
1) Past project experience: This is most probably the most basic thing you need first. Try to identify something similar that you have worked on in the past or that someone you can talk with has worked on in the past. In each project, the time, it takes to develop a test case or to do execute each test case is different. So if you do not have any experience on working on such a project, you may estimate too low or high.

2) Write down a work breakdown structure: List down all the activities you need to perform in this project such as test plan preparation, test case design, test data prep and test execution, etc. Again from step #1 identify the various tasks and activities that were involved in the past work and map them to the new work you are planning. As part of this identified places where there is something new to you and seek help from someone who has had experience with those activities and tasks. Have that person to identify things you have missed. Allocate time to each of these tasks based on the volume of work. For example, if you need to write 100 test cases for a project, and it takes 30 minutes to write a test case, then put 3000 minutes or 3000/60 = 50 hours (also called person hours, man hours) for the task test case creation Similarly fill up all the task hours.

3) Put some contingency plan: Try to remember the problems and issues that you may have run into the past project and how much those problems and issues helped or hurt the original schedule. Then as you are looking over things, ask yourself questions such as: (1) what happens is someone’s family member dies, and they have to deal with that, (2) what happens if someone is sick, (3) what happens if someone leaves the organization for someplace else, (4) what happens if equipment and gear are not delivered on time, (5) what happens if a deliverable is delayed or the quality is not sufficient.
Add the impact of those problems and issues into what you remember from the past work. Remember it is always better to over estimate than putting less time. On the top of estimation in step 2 put some buffer hour based on the risks you have identified. So it can be 10% to 30% of the total effort. For example, in the step #2 you have total effort found 1000 Person Hours then put another 30% on the top of that, and the test effort would become 1300 PDs.

4) Perform a top down Estimation: Now above we have found the effort of testing using a bottom of approach. However, when you put that in a project plan, the overall estimation will be even more because of the external dependencies or activity other than testing. So until a code is delivered you cannot start your testing. For example, Module A might be delivered on 23 Feb by the Dev team where as the test case writing and test data prep for Module, A is done on 20th February. In this situation, though you are 100% ready for testing, but you cannot start the test as the code would not be ready. So test execution for that module would take 3 more days than what you estimated originally. Similarly add all those dependencies, and you will see your overall test estimation become more than your bottom-up estimate. Generally, this will be 10 to 20% more than what you estimated before.

5) Review and approval: Finally, walk through your estimations with a couple of people, having them review them. If possible try to do a simulation with pencil and paper, drawing some diagrams about how things fit together, concentrating on deliverables and timing. Remember there are different kinds of deliverables such as documents (formal and informal), decisions, reviews, and actual testing work that result in documents (test reports, service reports documenting defects, etc.)

New here? Like us on Facebook to stay updated of new posts.

About the Author

Leave A Response