Software Test Estimation: Percentage of a project estimated effort allocated to software testing

If you want to learn about Test Estimation, first view my below video on Test Estimation with formula example and Questions and Answers.

Now if someone asked me about the project estimated effort percentage that should be allocated to software testing, my reply would be as follows:

There is no “magic” formula to estimate the effort percentage for software testing although some companies do use some sort of a formula to guide their estimation. Here are some tips to guide arriving at a percentage while keeping the uniqueness of the project in mind:

 

1. Consider the size of the project. Projects with a bigger size tend to be substantially (if not exponentially) more complex than small projects. Bigger projects may require several cycles of testing and bug fixing.

 

2. Consider the risks faced in the project:

a. Is the project in a domain that is new for the project team? There is the danger of misinterpreting the requirements in such a case.

b. Are the developers (relatively) new to the technology?

c. Is the project dependent on third-party components, tools or services?

d Are the client, end-users and other stakeholders new to the team or not easily approachable to the team due to any reason?

 

3. Search historical data on similar projects.

 

4. Your company may have a (rough) formula to arrive at the effort percentage. Talk to other project managers and test managers to find out about any formula in vogue.

 

5. Consider the consequences of a variance from the estimated effort. Would it be possible to absorb an effort slippage internally (within the company) or externally (in agreement with the client)?

 

6. Consider the expectations of the stakeholders. A client may not agree to a high percentage. In such a case, clarify with the company management that effort overruns would be absorbed internally without issue.

 

I read somewhere before that many people allocate between 10% and 29% to software testing. However, use the tips above to guide you to your own estimate.

Open Source Software Test Tools

On several forums, I have noticed many testers looking for open source testing tools. Here are two great lists:

1. Open source functional test tools
2. Open source performance test tools

The story of Rich Tester and Poor Tester

Even though we may not realize it at the time, the way in which we approach our work sometimes has a profound impact on our future. Let me explain this with the help of a story that I have made up. This story is about two testers who faced identical circumstances. The two even had very similar knowledge about the craft of testing. The only difference was that one of them earnestly wanted an opportunity to make her mark in testing.

Once upon a time, there were two testers working in a company. The company started a project in which two testers were required. Our two testers were assigned to the project with hopes (as always) of successful testing. However, only the Rich Tester (though she did not think of herself as such at the time) had been eagerly waiting for such a chance.

As usual, the initial period of the project was used for the purpose of knowledge transfer and knowledge building about the application under test. Both the testers were serious about gaining in-depth functional knowledge about the application. Both of them asked a lot of questions to the trainers and obtained clarifications to their queries. The Poor Tester stopped at that but the Rich Tester did not. The Rich Tester took the time to build her own notes about the problem areas of the application, the problems that she observed and the areas of the application that she would like to explore in detail.

Soon enough, the period of knowledge transfer finished and the day came when the two testers were provided a recent build of the application. Their Test Lead divided the test items between the two. As expected of her, the Poor Tester executed the test cases on her assigned test items and logged the defects in the issue tracking system. But the Rich Tester did not immediately start the execution of her test cases. She performed a sanity test on the application. She found a few high-level problems. Then she executed the test cases on her assigned test items. She logged both the high-level defects as well as the defects in her assigned test items. The result was that the Rich Tester was able to find a few more and a few more important defects.

As subsequent builds of the application came up, the Poor Tester stuck to her assigned test items. Since the available test cases listed only positive tests, she limited her test execution to only positive testing. However, things went differently for the Rich Tester. On a new build of the application, she would start with the usual sanity test. Then she would execute her assigned test cases but did not limit herself to the test data listed in her test cases. She designed other interesting test data and executed her test cases with that as well. She spent the remaining test execution time to design and execute negative tests in her assigned areas. There was now an observable difference in the outputs of the two testers. Generally, the Rich Tester was able to find either defects with a bigger impact or simply more defects than the Poor Tester.

There was no stopping the Rich Tester. She utilized the time between the builds to automate the generation of certain test data as well automate the sanity tests. Automated generation of test data saved a substantial period of time that she could now devote to an even more thorough round of testing. She started her automated tests every evening before she left for the day and analyzed the test results the next morning. Due to the quality of the defects raised by her, the Rich Tester had established a better perception in the minds of the stakeholders of the project. For the Poor Tester, things had remained fairly static.

Fast forward a couple of years. The Poor Tester was still testing (efficiently, mind you but by the book). However, the Rich Tester had impressed the stakeholders in her previous projects. She was considered a role-model for other testers and was now leading a team of her own. Soon, she would be in consideration for a role as Test Manager.

We can realize from this short story that it is in our best interest to not wait to be asked but to push the boundary as far as possible. We should find the means to make a bigger impact and magnify our output.