What is test effort estimation?
Test effort estimation is a key activity in test planning. A well-thought effort estimate helps to rightly plan the testing phases, allocate the required resources, schedule the testing activities so that the testing phase gets completed on-time.
Irrespective of the SDLC models that you have for your testing project, a certain level of effort estimations is needed. In this blog, we will discuss a few quick tips on how to calculate the effort estimates for some key testing activities.
Test Estimation Technique
One of the widely used techniques for test estimation is the ‘Work Breakdown structure’. The other common effort estimation techniques are ‘Function point analysis’ and ‘Poker game technique’ etc. We will look at the Work Breakdown structure in a little more detail along with areas to focus on for each test activity type.
For a testing project, test activities at a high level can be divided into the following:
- Requirements, review, and learning
- Test Design
- Test Execution
- Defect reporting and retesting
- Other misc. project management activities
a) Requirement Analysis & Exploratory Testing
Before starting any testing activity, the requirements of the product must be clearly understood. A quick way to understand these is to review the mock screens/wireframes or interact with the application prototype, if available, and then conduct exploratory testing or just review the textual requirements description and visualize the application. Depending on the size and complexity of an application, an effort of 1 to 2 weeks of time is needed for any tester to get a sense of the requirements.
b) Test Design Estimation
It is a process, which describes how testing should be done. It also includes creating test cases based on defined test conditions as well as preparing test data. The key activities involved in this process are:
- Identify the list of test scenarios
- Write detailed test cases
- Peer review (Optional)
1. Identify a List of Test Scenarios – This is the basis for calculating test design effort estimations. The testing team, with their collective knowledge of the requirements, could brainstorm together and list out the possible test scenarios. Mind maps can be used as tools to capture the collective thoughts on test scenarios. Depending on the length and complexity of the application, this activity could take anywhere from a few days to a few weeks.
2. Writing Detailed Test Cases – Effort estimation for writing a detailed test case can be calculated based on the following parameters and categories:
- Number of test steps
- Number of test verifications
The above example is just indicative and could vary across projects
The effort estimate for test design would be:
(# of simple test cases * 5 mins) + (# of moderate test cases*10 mins) + (# of complex test cases * 20 mins) + Brainstorming effort for ideating test scenarios
c) Test Case Execution
Test execution is the process of executing the test cases that were identified and designed in the application, by comparing the expected and actual results. The activities involved in this task are:
- Preparation of test data/test environment
- Execute the test cases and mark test result
Preparation of test data – Test data preparation is an activity that involves setting up some pre-conditions in the application that are needed to write/execute a test case. This activity depends on the complexity of the application, tools available to set up the test data (a prod like a database restore, make a bunch of API calls, import test files, etc.) and could take anywhere from a few days to a week.
Execute the Test Cases- The test execution effort estimate is usually based on the following parameters:
- # of test cases
- # of test platforms (e.g. browsers, mobile devices, operating systems)
- # of test execution iterations i.e. number of times the test cases were expected to be executed before the final release
- # of test environments (e.g. QA, Staging, UAT, Prod, etc.)
The following categories can serve as guidelines for test case execution on a single platform and environment:
The effort estimate for test execution would be
(# of simple test cases * 2mins) + (# of moderate test cases* 5mins) + (# of complex test cases * 10 mins) * # of test iterations * # of test platforms + test data preparation effort
d) Defect Reporting & Retesting Estimates
Defect reporting helps in identifying the problem clearly so that the developers can replicate the defect easily and fix it.
Generally, defect reporting and retesting is a ballpark estimate to be considered, as we cannot foresee the number of defects to be found at the effort estimation stages.
Activities performed in defect reporting are:
- Log defects with appropriate test evidence
- Retest defects once they are fixed
While there are many ways to calculate effort estimation for this phase, one quick way is to consider a certain percentage of test execution. Consider 5-10% of the test execution effort for defect reporting and retesting. This could be a good way to start and the effort estimate should be revised as the project progresses.
e) Project Management and Co-Ordination Estimates
Apart from the core testing tasks, delivering a testing project could also involve a few miscellaneous project management tasks such as meetings, reviews, preparing test reports, providing demonstrations, etc. Consider 30 mins – 1 hour per day as a good way to start and these effort estimates should be revised as the project progresses.
Other tips to follow for test effort estimations
- Consider 5 to 10% as buffer time as unpredictable things might happen anytime. This will help testers to cope with delayed responses emerging from delay in bug fixes, test environmental instability, minor changes in test requirements, etc.
- Consider the skill and experience level of the people while calculating the effort estimates. The examples given in points a, b, c, and d sections above could vary from a junior tester to a senior tester.
- Follow the defined review process by conducting team retrospectives as these play a vital role while preparing good estimates due to possible similarities across projects, organizations, or even industry.
By: Hima Chilukuru and Pratyusha Chitturi