Tips & Techniques for Estimating Software Testing Effort

Even before we go about looking into tips and techniques for doing effort estimation for testing, it may be kept in mind that testing can be secluded as a separate task. It starts with the start of the project by starting to analyzing the project requirements and come up with a test plan comprising of test cases (primarily) and goes on till the end in form of performing the tests. However, it may be good idea to understand different aspects of testing to be done in the project and assign efforts accordingly if the testing includes specific attention due to various different reasons. Also, different software development methodologies such as waterfall or agile have a slightly different approach for overall testing of the software and may need to estimated appropriately.

Also, it may be good to understand what we are trying to estimate in form of testing. Is it just about testing the software to create the bugs or both testing and fixing the bugs?  I have seen that later is taken into consideration. However, many could argue that this, then, may not be called as effort estimation for testing as this is part of development itself. 🙂

Below represents the tips and techniques for effort estimation of testing if we are considering testing activities separately and not really considering bugs fixing as part of it. Before we talk about effort estimation techniques for testing on any specific project, following are some of the topics that would be good to understand beforehand:

[adsenseyu2]

• Testing objectives: This is very important to understand the objectives of testing the system. These may be related with both functional and non-functional requirements of the system. For example, it is good to have highly performing system. But, it may not be of priority at the time of effort estimating due to expected load on the system. Thus, the effort estimation could completely skip the aspect of performance. Similar is the case for security testing. In some cases, the application may be of only internal usage and may not be needed to expose on internet. Thus, security testing may take back seat in that case.
• Size of the system: This is important to understand if we are estimating for a large project consisting of multiple sub-systems or a smaller project consisting of just one application. Some of well-known techniques to understand the size of the system is in terms of function-points (speaks primarily about complexity), story points (when working with agile).
• Different kinds of testing: It would be good to determine different kind of testings that will be required to be performed in order to achieve quality assurance objectives. Following are some of the different kind of testings that are done: functional testing, integration testing, load/stress testing, regression testing, user acceptance testing etc.
• Constraints around testing: It may be good idea to determine the related project constraints such as availability of resources, overall budget set aside for testing, availability of tools and frameworks etc.
• Peripheral activities around testing: It may also be good idea to understand different activities that needed to be done as part of the testing. This is because time and effort also goes in these kind of activities. These activities may include tasks such as creating test reports, logging/collaborating on test defects in defect management system etc.
• Number of Test Cycles:  It would be good to determine how many cycles of testing may be requires to be completed in order to achieve QA objectives.

Following are some of the different techniques that could be used to do estimation for software testing:

1. Heuristics-based: Try and get an access to historical data on similar projects done across your organization. If not enough, try and get information from places such as LinkedIn groups, Google groups, and other testing communities.
2. Delphi Approach: In this technique, the effort is independently estimated by different expert testing professionals and then, processed later to come up with one final estimate. However, the key need for this approach is to have presence of expert testing professionals.
3. Convert Software-size to Testing Effort: Using technique such as function-point analysis for estimating size of the software in terms of complexity and hence, effort, also helps you determine effort for testing based on the framework.
4. Work Breakdown Structure (WBS) based: In this technique, one identifies different tasks and estimate accordingly. Tasks may include some of the following such as creating a test plan, creating test cases, creating test environment, test execution, test reporting etc. This one works like charm for many as it provides lot of clarity and helps you to create a process around testing.