Is there any test estimation technique other than work breakdown structure and test point analysis?
Which kind of test estimation technique should be used for different types of projects?
Printable View
Is there any test estimation technique other than work breakdown structure and test point analysis?
Which kind of test estimation technique should be used for different types of projects?
Hi,
Other than WBS and Test Point Analysis, we can estimate effort for testing based on Function Point Analysis, Use-case analysis methodology.
Function point Analysis (FPA) is more or less based on the Functions involved in the AUT. We try tooo break down the application in terms of External Input, Internal Input, External Output, Internal Logic Files, External Logic files and try to estimate the Unadjusted Function Point.
We also take into consideration the 14 General System charactersitics and use this as measure to derive the Adjusted Function Point Value. Using the AFP value, we can derive - Effort, Cost of testing required.
We generally decide the estimation techinique based on the application under test. Incase the application is pretty complex and involves lot of internal algorithms, we prefer to use WBS as it absolves of any of this complexity.
But incase we wish to go as per Functional flow and components involved in testing, we prefer Use-case analysis.
Cheers...
I won't repeat the information provided in the previous post. Instead, I will add some things to consider when estimating test effort. Much of this is simply common sense, but they are things that nevertheless should be addressed:
The two primary elements in test estimation are time and resources. Your estimation needs to take both into account.
There are many questions you need to answer in order to estimate a test effort. The more accurate and thorough your answers to these questions the better your test estimation.
1) What is the value of the application to your customers and your company? The greater the perceived value, the more stringent the exit criteria will be. The tighter the reigns on the exit criteria, the more test iterations it will take to complete the testing process and release the product.
2) What modules or functionalities will be tested and how many testers are available to test them? Of course as functionalities increase and/or number of testers decrease the more time it will take to thoroughly test the application.
3) What is the complexity of each of these modules or functionalities? As the complexity increases the more time and effort will be required to understand the application create test plans create test cases execute test cases regress test cases and retest defects.
4) How many test iterations (test runs) will be required to complete the test project? This is also related to complexity. As an application becomes more complex it will typically require more test iterations to reach the company's exit critera (the number of open defects by severity and priority that a company can live with).
5) How much time will be required by developers to produce fixes for new builds between test runs? Complexity is also a factor here. As an application becomes more complex there are often more dependencies between modules and functionalities. This often requires coordination between developers. Consequently this takes more time. This is important because your estimation must also include the amount of time testers are waiting for the next build between test runs.
6) What is the average number of defects that you anticipate will be found during each test run? You may have already guessed that complexity is a factor here too. The more complex an application the greater number of defects will reach the test team when the application is released to them. In addition the more complex the application the more likely that severe and high priority defects will be found in later stages of the test process.
7) How reliable are cross-functional groups that provide deliverables to the test team that are of high quality and on a timely basis? For example if the business requirements miss important functionalities then more time will be required to recover from this oversight. Oftentimes your history with these groups will help you decide how to handle these risk factors in your estimation.
8) Don't forget that an 8-hour day is not entirely devoted to core responsibilities. Testers go to meetings read and respond to emails and do other activities that consume time throughout the day. This needs to be factored into your estimation as well.
ONE MORE TIP:
The first thing I do in order to estimate test time and resources is to facilitate a business requirements review with all my testers. By reviewing the requirements with them it gives me a good idea about the complexity of the application. At the end of this meeting I assign functionalities to each tester. I give them several days to pour over their requirements again and get a good feel for their areas and then I ask them how much time they believe they will need to 1) produce test plans 2) produce test cases 3) map requirement to test cases. Typically I will take these numbers and apply a multiplier to account for their optimism as well as overall risks.
There is more to estimating than I have described in this answer but I believe it gives you a good foundation to begin with.