testing estimation process
The testing estimation process in place was quite simple. The inputs for the process, provided by the development team, were: the size of the development team and the number of working days needed for building a solution before starting systems tests.
The testing estimation process said that the number of testing engineers would be half of the number of development engineers and one third of the number of development working days.
A spreadsheet was created in order to find out the estimation and calculate the duration of tests and testing costs. They are based on the following formulas:
Testing working days = (Development working days) / 3.
Testing engineers = (Development engineers) / 2.
Testing costs = Testing working days * Testing engineers * person daily costs.
As the process was only playing with numbers, it was not necessary to register anywhere how the estimation was obtained.
To exemplify how the process worked, if one development team said that to deliver a solution for systems testing it would need 4 engineers and 66 working days then, the systems test would need 2 engineers (half) and 21 working days (one third). So, the solution would be ready for delivery to the customer after 87 (66+21) working days.
Just to be clear, in testing time, it was not included the time for developing the testcases and preparing the testing environment. Normally, it would need an extra 10 days for the testing team.
The new testing estimation process
Besides being simple, that process worked fine for different projects and years. But, I was not happy with this approach and my officemates from the development group were not, either. Metrics, project analogies, expertise, requirements, nothing were being used to support the estimation process.
I mentioned my thoughts to the testing group. We could not stand the estimation process for very long. I, myself, was not convinced to support it any more. Then, some rules were implemented in order to establish a new process.
Those rules are being shared below. I know that they are not complete and it was not my intention for estimating but, from now, I have strong arguments to discuss my estimation when someone doubts my numbers.
The Rules
1st Rule: Estimation shall be always based on the software requirements
All estimation should be based on what would be tested, i.e., the software requirements.
Normally, the software requirements were only established by the development team without any or just a little participation from the testing team. After the specification have been established and the project costs and duration have been estimated, the development team asks how long would take for testing the solution. The answer should be said almost right away.
Then, the software requirements shall be read and understood by the testing team, too. Without the testing participation, no serious estimation can be considered.
2nd Rule: Estimation shall be based on expert judgment
Before estimating, the testing team classifies the requirements in the following categories:
• Critical: The development team has little knowledge in how to implement it;
• High: The development team has good knowledge in how to implement it but it is not an easy task;
• Normal: The development team has good knowledge in how to implement.
The experts in each requirement should say how long it would take for testing them. The categories would help the experts in estimating the effort for testing the requirements.
3rd Rule: Estimation shall be based on previous projects
All estimation should be based on previous projects. If a new project has similar requirements from a previous one, the estimation is based on that project.
4th Rule: Estimation shall be based on metrics
My organization has created an OPD, Organization Process Database, where the project metrics are recorded. We have recorded metrics from three years ago obtained from dozens of projects.
The number of requirements is the basic information for estimating a testing project. From it, my organization has metrics that guide us to estimate a testing project. The table below shows the metrics used to estimate a testing project. The team size is 01 testing engineer.
Metric Value
1 Number of testcases created for each requirement 4,53
2 Number of testcases developed by Working day 14,47
3 Number of testcases executed by Working day 10,20
4 Number of ARs for testcase 0,77
5 Number of ARs verified by Working day 24,64
For instance, if we have a project with 70 functional requirements and a testing team size of 2 engineers, we reach the following estimates:
Metric Value
Number of testcases – based on metric 1 317,10
Preparation phase – based on metric 2 11 working days
Execution phase – based on metric 3 16 working days
Number of ARs – based on metric 4 244 ARs
Regression phase – based on metric 5 6 working days
The testing duration is estimated in 22 (16+6) working days. Plus, 11 working days for preparing it.
5th Rule: Estimation shall never forget the past
I have not sent away the past. The testing team continues using the old process and the spreadsheet. After the estimation is done following the new rules, the testing team estimates again using the old process in order to compare both results.
Normally, the results from the new estimate process are cheaper and faster than the old one in about 20 to 25%. If the testing team gets a different percentage, the testing team returns to the process in order to understand if something was missed.
6th Rule: Estimation shall be recorded
All decisions should be recorded. It is very important because if requirements change for any reason, the records would help the testing team to estimate again. The testing team would not need to return for all steps and take the same decisions again. Sometimes, it is an opportunity to adjust the estimation made earlier.
7th Rule: Estimation shall be supported by tools
A new spreadsheet has been created containing metrics that help to reach the estimation quickly. The spreadsheet calculates automatically the costs and duration for each testing phase.
There is also a letter template that contains some sections such as: cost table, risks, and free notes to be filled out. This letter is sent to the customer. It also shows the different options for testing that can help the customer decides which kind of test he needs.
8th Rule: Estimation shall always be verified
Finally, All estimation should be verified. I’ve created another spreadsheet for recording the estimations. The estimation is compared to the previous ones recorded in a spreadsheet to see if they have similar trend. If the estimation has any deviation from the recorded ones, then a re-estimation should be made.
The testing estimation process said that the number of testing engineers would be half of the number of development engineers and one third of the number of development working days.
A spreadsheet was created in order to find out the estimation and calculate the duration of tests and testing costs. They are based on the following formulas:
Testing working days = (Development working days) / 3.
Testing engineers = (Development engineers) / 2.
Testing costs = Testing working days * Testing engineers * person daily costs.
As the process was only playing with numbers, it was not necessary to register anywhere how the estimation was obtained.
To exemplify how the process worked, if one development team said that to deliver a solution for systems testing it would need 4 engineers and 66 working days then, the systems test would need 2 engineers (half) and 21 working days (one third). So, the solution would be ready for delivery to the customer after 87 (66+21) working days.
Just to be clear, in testing time, it was not included the time for developing the testcases and preparing the testing environment. Normally, it would need an extra 10 days for the testing team.
The new testing estimation process
Besides being simple, that process worked fine for different projects and years. But, I was not happy with this approach and my officemates from the development group were not, either. Metrics, project analogies, expertise, requirements, nothing were being used to support the estimation process.
I mentioned my thoughts to the testing group. We could not stand the estimation process for very long. I, myself, was not convinced to support it any more. Then, some rules were implemented in order to establish a new process.
Those rules are being shared below. I know that they are not complete and it was not my intention for estimating but, from now, I have strong arguments to discuss my estimation when someone doubts my numbers.
The Rules
1st Rule: Estimation shall be always based on the software requirements
All estimation should be based on what would be tested, i.e., the software requirements.
Normally, the software requirements were only established by the development team without any or just a little participation from the testing team. After the specification have been established and the project costs and duration have been estimated, the development team asks how long would take for testing the solution. The answer should be said almost right away.
Then, the software requirements shall be read and understood by the testing team, too. Without the testing participation, no serious estimation can be considered.
2nd Rule: Estimation shall be based on expert judgment
Before estimating, the testing team classifies the requirements in the following categories:
• Critical: The development team has little knowledge in how to implement it;
• High: The development team has good knowledge in how to implement it but it is not an easy task;
• Normal: The development team has good knowledge in how to implement.
The experts in each requirement should say how long it would take for testing them. The categories would help the experts in estimating the effort for testing the requirements.
3rd Rule: Estimation shall be based on previous projects
All estimation should be based on previous projects. If a new project has similar requirements from a previous one, the estimation is based on that project.
4th Rule: Estimation shall be based on metrics
My organization has created an OPD, Organization Process Database, where the project metrics are recorded. We have recorded metrics from three years ago obtained from dozens of projects.
The number of requirements is the basic information for estimating a testing project. From it, my organization has metrics that guide us to estimate a testing project. The table below shows the metrics used to estimate a testing project. The team size is 01 testing engineer.
Metric Value
1 Number of testcases created for each requirement 4,53
2 Number of testcases developed by Working day 14,47
3 Number of testcases executed by Working day 10,20
4 Number of ARs for testcase 0,77
5 Number of ARs verified by Working day 24,64
For instance, if we have a project with 70 functional requirements and a testing team size of 2 engineers, we reach the following estimates:
Metric Value
Number of testcases – based on metric 1 317,10
Preparation phase – based on metric 2 11 working days
Execution phase – based on metric 3 16 working days
Number of ARs – based on metric 4 244 ARs
Regression phase – based on metric 5 6 working days
The testing duration is estimated in 22 (16+6) working days. Plus, 11 working days for preparing it.
5th Rule: Estimation shall never forget the past
I have not sent away the past. The testing team continues using the old process and the spreadsheet. After the estimation is done following the new rules, the testing team estimates again using the old process in order to compare both results.
Normally, the results from the new estimate process are cheaper and faster than the old one in about 20 to 25%. If the testing team gets a different percentage, the testing team returns to the process in order to understand if something was missed.
6th Rule: Estimation shall be recorded
All decisions should be recorded. It is very important because if requirements change for any reason, the records would help the testing team to estimate again. The testing team would not need to return for all steps and take the same decisions again. Sometimes, it is an opportunity to adjust the estimation made earlier.
7th Rule: Estimation shall be supported by tools
A new spreadsheet has been created containing metrics that help to reach the estimation quickly. The spreadsheet calculates automatically the costs and duration for each testing phase.
There is also a letter template that contains some sections such as: cost table, risks, and free notes to be filled out. This letter is sent to the customer. It also shows the different options for testing that can help the customer decides which kind of test he needs.
8th Rule: Estimation shall always be verified
Finally, All estimation should be verified. I’ve created another spreadsheet for recording the estimations. The estimation is compared to the previous ones recorded in a spreadsheet to see if they have similar trend. If the estimation has any deviation from the recorded ones, then a re-estimation should be made.
Comments
Post a Comment