Challenge Your Performance Test Estimation Effort Using Test Factors
Challenge Your Performance Test Estimation Effort Using Test Factors
Challenge Your Performance Test Estimation Effort Using Test Factors
Oct 2006
ABSTRACT
Performance Test effort estimation is the initial challenge we face in the Performance Test Lifecycle. As Performance Testing is more like an investigation activity which may take any direction, the ad-hoc estimation methodologies used for performance test estimation doesnt seem fruitful. Because of the dynamisms and varying scope, there are lots of issues in the test effort estimation. Based on our experience in the performance testing projects on the web based applications, we conjecture that the Performance Test Estimation approach using Test Factors could be more reliable. Our approach is based on the consideration of the various test factors involved in scripting, execution and analysis, thereby eliminating the use of ad-hoc estimation methodologies and it is architecture / technology independent.
This paper describes how to do effort estimation for a performance testing project. The paper focuses on the pre-requisites and the factors which need to be analyzed in order to arrive at the performance estimation model along with the details about how to use this estimation model. This approach is being implemented in Honeywell for the estimation of Performance Testing effort on web applications and is proven to be ninety-five percent accurate. Its been used to estimate ten projects falling under simple, medium and high complex project categories. The case study illustrates the application of this technique to arrive at the estimation for a typical web application.
The readability of the paper covers Performance Test Engineers, Test Leads, Test Managers and others with the domain knowledge of performance testing.
1.0 Introduction
Organizations generally like to make the headlines with their success stories and not about the failure web sites due to unexpected user load. Industry study reveals that poor performing IT applications cost industrialized nations almost $45 billion annually. Most of the organizations understand the importance of performance testing and the impact of bypassing it. How much time would it take to do the performance testing of an application? is a million dollar question for all organizations wherein the Software Performance Engineering (SPE) is not in place from the start of the project. Most of the organizations plan for the performance testing of the applications towards the end of the project, though it is of great importance to decide whether the performance bottlenecks are addressed before the go-alive dates.
Scott Barber rightly compares the Performance testing to crime investigation. It is tough to arrive at the effort estimation before investigating the system performance. This paper describes how to approach the performance test estimation for web applications and illustrates it with a case study. Its assumed that the reader is familiar with the performance test activities involved.
Most of the Organizations use ROM (Rough Order of Magnitude) estimation based on the historical data & technical risk factors. For them, the test estimation effort is validated through the following breakup.
The Performance Test Planning phase contributes to 20% of the total effort. The Test Script generation contributes to 30% of the total effort. The Test Execution activities contribute to 45% of the total effort. The Performance Test Reporting contributes to 5% of the total effort. Various activities are carried out during each phase of performance testing as listed in the section 1.3. The importance of the activities carried out in each of the phases depends on the scope of the project which needs to be tested for its performance. In most of the cases, replanning is frequently required during the Test Execution Phase because of its dynamic nature. Projects planned for specific tests may end up having multiple rounds of unplanned tests because of the last minute surprises.
The Test Factors of a phase is associated with three values namely Importance Factor, Test Scope Factor and Test Complexity Factor. The Importance Factor is already defined (set as part of the estimation model) & it remains constant throughout the estimation. The Test Scope Factor needs to be set by the estimator based on the project. The Test Complexity
Factor is derived out as the product of the Importance Factor & the Test Complexity Factor. The Total Complexity Factor of the phase is the sum of the individual Test Complexity Factors of the phase divided by the number of test factors of the phase.
These three values are represented in specific way for each of the above mentioned six phases. The Importance Factor [IF] for all the test factors of each phase is represented with a specific superscript along with IF. For example, the Importance Factor for all the test factors in Test Strategy phase is represented as IFts. The Test Scope Factor [TSF] for all the test factors of each phase is represented with a specific superscript along with TSF. For example, the Test Scope Factor for all the test factors in Scripting phase is represented as TSFs. The Test Complexity Factor for all the test factors of each phase is represented with a prefix along with CF. For example, the Complexity Factor for all the test factors in Environment Setup phase is represented as ESCF.
The sum of the product of all Importance Factor [IF] and the Test Scope Factor [TSF] of a phase divided by the number of test factors available in a phase gives the Total Complexity Factor of the phase which is the total effort required for completing a phase in hours.
Scope Factor [TSF]. The Complexity Factor naming conventions with respect to each phase is available in the Figure3.
Determine the TSFs [Test Scope factor] for each of these Test Factors & calculate the Scripting Complexity Factor [SCF] against each factor. The Total SCF is the sum of the products of each IFts & its corresponding TSFs.The Total SCF value represents the effort required for a Script in hours. In the same way, calculate the SCF value for each of the script. The SCF value can be calculated using the below formulae Total SCF = sum (prod (IFs, TSFs))/7 + [sum (prod (IFs, TSFs))/7] .
Final Performance Test Effort = TSCF + SCF + ESCF + BBCF + TECF + TRCF + 10% of estimated effort (for Project Complexity) + 10% of estimated effort (Management activities).
2. Estimate the Scripting effort Total SCF = [sum (prod (IFs, TSFs))/7*3] + [sum (prod (IFs, TSFs))/7 * 4]
3. Estimate Test Environment Setup effort Total ESCF = sum (prod (IFes, TSFes))/4
4. Estimate Baseline & Benchmarking effort Total BBCF = sum (prod (IFbb, TSFbb))/2
5. Estimate Test Execution effort Total TECF = (sum (prod (IFte, TSFte))/7) + (sum (prod (IFte, TSFte))/7) + (sum (prod (IFte, TSFte))/3)
6. Estimate Test Reporting effort Total TRCF = 4 + sum (prod (IFtr, TSFtr))/3
7. Final Test Effort Calculation Final Performance Test Effort = TSCF + SCF + ESCF + BBCF + TECF + TRCF + 10% of estimated effort (for Project Complexity) + 10% of estimated effort (Management activities). Final Performance Test Effort = 403 + 40.3 + 40.3 = 483.6 hours
4.0 Limitations
The estimation model based on Test Factors has the following limitations. 1. If the Performance Test Focal is not in the Practitioner Level of competency in Scripting, Test Execution & Analysis, then the estimated effort will not be accurate. 2. If the project includes any other specific activity other than the activities mentioned in the assumptions, then the estimated effort will not be accurate. For addition of any new activity, the test factors that would impact the efforts need to be identified. 3. The estimation will not cover the extra effort required, when there is a slippage from the external teams / customer for providing their inputs / tasks dependent on them.
Author Biography
I am an energetic Software Test Engineer with 4 years of extensive experience in System, Integration & Performance testing. I love to
work in a challenging environment which synergies my conceptual & technical skills coupled with hard work & determination. I turned out to be a Software Tester from being a developer in Microsoft platforms because of my passion towards testing. I have been working in J2EE, .NET & Client-Server applications as a system tester. I have more interest towards Model Based Testing approaches & Functional Test Automation using scripting languages like Ruby & Perl. I am working in the Performance Engineering field for the past 1+ year. As a performance engineer my responsibilities would include deriving the application usage model, generation of performance test scripts & bottleneck analysis. My other interests would include Security Testing.