Techniques to provide a Test Estimation for the Project

Overview

In software Lifecycle Management, the test initiation phase comprises test estimation and Proposal Decks. What is Test Estimation? Why do we need to perform Estimation for all Engagements? This is the question all testers and Leaders will have in their minds. Let us discuss them in depth and the various techniques to achieve the Test Estimation appropriately.

Data In software Lifecycle Management, the test initiation phase comprises test estimation and Proposal Decks. What is Test Estimation? Why do we need to perform Estimation for all Engagements? This is the question all testers and Leaders will have in their minds. Let us discuss them in depth and the various techniques to achieve the Test Estimation appropriately.

Test Estimation plays a vital role in each engagement we work on. To find out or assess how long the tasks and testing activities will take to complete and deliver with Cost and resources, Test Estimation is more important.

What should I estimate?

Timeline: Based on the Testing Methodology or Model proposed by the business, work out the timeline required for the Project or Engagement. Deadlines and deliverables should be effectively considered while deriving the timeline for the Product Release.

Cost: Basically, all engagements will be worked out based on the Budget Planned and requested. We need to analyse and come up with a solution for how much money we need to invest to complete this Project.

Resources: To achieve the agreed Deliverables, we need Human Resources, Material Resources, facilities, and Capital on time.

Skills: Human skills play a vital role in every deliverable. Right Leadership, Knowledge in Testing areas, Experience in tools and technology with which we work, Ability and Flexibility in work, and adapting to changes and culture also matter.

Techniques to derive Estimates.

Work Breakdown Structure –

This is the common and familiar way of performing Test Estimation for a Project. As a first step, we will breakdown the Project components into small pieces / executable groups. And these groups are further drilled down to multiple sub-groups or tasks in a measurable way.
Based on the split, we will measure the resources that need to be assigned for each task. Sizing each group based on a timeline and consolidating them phase-wise should give a considerable effort estimate. Post that, include Project Management activities effort and Buffer time to complete the estimates.

3 Point Estimation:

This is a statistical method of evaluating the Project Requirements. Each Requirement is broken into multiple sub-tasks, and then a 3-point estimation is applied to each sub-task.

• Optimistic Estimates: This is nothing but assuming a requirement will never go wrong and all conditions applied to that will stay positive. All resources are highly skilled and will stay until the Project is complete. No risk or crisis will pop up during the project timeline.

• Most likely Estimates: This is a typical case where we can expect a few challenges, but most of the tasks will go as expected. We should be able to drive the Project with the best and most skilled available resources, and no major crisis will come in our way.

• Pessimistic Estimates: In this case, our crew will have limited resources and an inappropriate skill set. Most of the tasks will deviate from our plan. Downtime and stability challenges in the development and testing phases will be encountered.

Keeping these scenarios in mind, we can put the estimates for each requirement together, and we can find the Medium Person days or Man hours to derive the final figure.

Percentage Distribution:

In this method, we can evaluate based on the scope and Phases of the Project. Split the testing phases according to the Software testing lifecycle and the types of testing planned to be delivered. Then, based on your previous experience or a similar Project’s experience, you can derive the Percentage for each Phase and Type. Have the overall estimates or manpower efforts in mind and split them according to the phases.

For example, if we are testing a Web Portal application, the below Percentage may work.

This technique should be used only if you have prior experience evaluating similar Projects. Moreover, you can improvise the estimates and shuffle the percentage across phases based on your previous Project’s metrics and the SME’s discussion.

This method is easy to apply, and it doesn’t require any specific tools to complete the testing effort.

Use Case or Test Case Point Estimation

This technique is also known as the Sizing method of estimation and is an extension of the Work breakdown structure method. We have already broken down the Project Requirements into modules, functionalities, and sub-tasks. After that, calculate the complexity of the sub-tasks for each type of testing. Complexity can be defined into 3 or 4 types based on the Project scale. Size the functionality based on the operations and test steps involved in your testing. It can be grouped as below:

Simple is between 1 and 3.
Medium is between 4 and 7.
Complex is between 8 and 16.
More Complex is between >16.

Based on the functional Test Case Point size, derive the estimates for each phase and calculate the final estimates.

Sample Test Estimation and Preparation

Keeping these Use case and Test case point factors in mind, below is the template derived to perform Testing in Multiple Environments, various types of Testing techniques, Multiple Iterations, covering all Phases, critical to Low complexity requirements, Test Data Management, Quality Monitoring activities, automation and performance scope testing, and warranty support.

We can include or exclude the factors based on our Business Requirements and Scope in the Test Estimation template to achieve our numbers.

Template Workbook Contents

Cover Page: Provide Author, Document version, and Published Date details.

Requirements Sheet: Have a requirement sheet for classifying the requirements into Simple, Medium, and Complex categories.

ST/SIT/E2E/UAT: Detailed sheet for grouping the requirements into Simple, Medium, and Complex categories based on the Testing Type.

TCP Template: Jot down the types of testing (ST, SIT, E2E, etc.) along with the Size of the testable requirements (Simple, Medium, or complex) in a table format. Put down the values for each requirement based on the complexity of your application. The following is an example: more rows within each table (Interfaces, Reports, Extensions, etc.) and more tables can be added as required:

Based on the Test Case Points, calculate the efforts for each phase using productivity. For example, Test Design can take 20 minutes for each testable requirement and 30 minutes for Test Execution.

Effort Summary: A Phase-wise Effort Summary should be calculated based on Percentage distribution, whereas Test Design and Test execution phase efforts are derived from the above TCP methodology.

Assumptions: Have a worksheet for putting down the General Assumptions we considered for evaluation and the functional assumptions.

Best Practices to Follow While We Do Estimation

Remember your experience: Increase or Decrease the estimates based on the Metrics you achieved in your previous Projects. Points to consider are Productivity variations, Test Management activities, Defect rates, and Resource Skill sets.

Risk/Mitigation Plan Factor: We bumped up the number in the Design and Execution Phase considering Resource availability, Access and Environment Downtime issues, and Code Quality.

Add buffer time: have 2 to 5% extra efforts derived in Requirement gathering, Test Management Activities, and the closure phase to catch up on Domain knowledge, New Tool studies, and unexpected challenges during the project under test.

Stick to your estimation: Estimation may go in deviation when we get along with the Project. So, it is always best to keep an eye on the estimation and make modifications if required. We should not expand the values after we fix them, except when we have change requests or Minor Enhancements to the scope.