Estimation is not an easy task. Estimating testing projects is harder. If there are no tools or methodology to support it, the estimation process is a nightmare for those responsible for it. This essay describes a real experience in the estimation process. It also shows some rules, metrics, tools, and tips that guide a testing team through the estimation process.
In my opinion, one of the most difficult and critical activities in IT is the estimation process. I believe that it occurs because when we say that one project will be accomplished in a such time by a such cost, it must happen. If it does not happen, several things may follow: from peers' comments and senior management’s warnings to being fired depending on the reasons and seriousness of the failure.
Before even thinking of moving to Systems test at my organization, I always heard from the development group members that the estimations made by the Systems test group were too long and expensive. Then, when I arrived at my new seat, I tried to understand the 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.
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