There are different standard and non standard methods for test estimation. In many product based companies, people utilize non standardized but conventional estimation methods to make things work. These methods might have developed over a continuous period accommodating hidden factors like nature of application under test, environment, and risk factors for that specific product/market. But these methods can’t be adopted as a generalized organization standard for a mature operation model.

Fact: Managers/Leads are not comfortable with software estimation work. But it is a required activity, so based on their past experience on one particular Product, Test Leads/Test Managers estimate the entire testing project (but for that Product only). Because they spent 1-2 or 2-3 or even more years on that particular product. But if they are asked to change company or shift to new product of entire different domain, then it is very hard for them to do estimation.
In this topic, we will discuss following methods for test estimation:
1. FIA (finger in the air) or best guess
2. Ad-hoc method
3. Experience Based – Analogies and experts
4. WBS
5. Delphi technique
6. Three-point estimation (successive calculation)
7. Function points / Test point Analysis
8. Percentage of development effort method
9. Percentage distribution
10. Use case point estimation method
 
Lets discuss one by one:
1. Best Guess – This technique is purely guesswork and based on the some sort of experience.
The method is very common, but since it is based on your gut feeling, its uncertainty contingency is probably around 200% or even higher.

2. Ad-hoc method – The test efforts are based on tentative timeframe. The timeline set by managerial or marketing personnel or by client without any guess/experience. Alternatively, it is done until the budgeted finances run out.
This is very common practise in extremely immature organizations and has error margins of over 100% at times.

3. Experience Based – Analogies and experts:

• Metrics collected from previous tests.
• You already tested similar application in previous project.
• Inputs are taken from Subject Matter experts who know the application (as well as testing) very well.

4. Work Breakdown Structure – It is created by breaking down the test project into small pieces. Modules are divided into sub-modules. Sub modules are further divided into functionalities and functionalities are divided in sub-functionalities.
Review all the requirements from Requirement Document to make sure they are added in WBS. Now you figure out the number of tasks your team needs to complete. Estimate the duration of each task.

5. Delphi technique – Same as above WBS. Here functionalities and each task is allocated to each team member. Then team member gives estimate that they will take this much hours to complete the task.
Averagely, this technique gives good confidence in the estimation. This technique can be combined with other techniques.

6. Three-point estimation – This technique is based on statistical methods In this technique, task is broken down into subtasks (similar to WBS) and then three types on estimation are done on each chunk –

• Optimistic Estimate (Best case scenario in which nothing goes wrong and all conditions are optimal.) = a
• Most Likely Estimate (most likely duration and there may be some problem but most of the things will go right.) = m
• Pessimistic Estimate (worst case scenario which everything goes wrong.) = b

Formula to find Value for Estimate (E) = a + (4*m) + b / 6
Standard Deviation (SD) = = (b – a)/6
More information about this technique can be find at:
http://www.projects.ed.ac.uk/methodologies/Full_Software_Project_Template/EstimationGuidelines.shtml

7. Function Point/Testing Point Analysis: The FP technique is a direct indicator of the functionality of software application from the user’s perspective. This is the most accepted technique used to estimate the size of a software project.
This technique is a part of TMap. Base of this technique is function point technique. Here we convert function points into test points. In Test Point analysis, we usually carry out the following:

• Dynamic Test Points
• Static Test Points
• Environmental Factor
• Productivity Factor
• Primary Test Hours
• Control Factor
• Total Test Hours

You can download the detailed self explained presentation here –
http://www.eurostarconferences.com/community/member/eurostar-presentations-archive/test-effort-estimation-with-test-point-analysis.aspx

In Testing, This estimation is based on requirement specification document, or a previously created prototype of the application. To calculate FP for a project, some major components are required.
The major components are:
Unadjusted Data Function Points: i. Internal Files, ii. External Interfaces
Unadjusted Transaction Function Points: User Inputs, ii. User Outputs & iii. User Inquiries
Capers Jones basic formula:
Number of Test cases = [Number of Function Points] x 1.2
Total Actual Effort, TAE = (Number of Test cases) * (Percentage of development effort /100)
This method is done in a case when a detailed low level design document or requirement document is available (i.e measure of function point is available) & Previous data for development and testing is available. But now days, when we are using agile and iterative methodologies to deliver projects, so most of the times all this documentation is not available.

8. Percentage of development effort method
Here the assumption is that a more complex business application may require more testing effort. The test effort required is a direct proportionate or percentage of the development effort.

Note: The development effort can be estimated using line of code (LOC) or function point (FP) which is not in the our scope.
Example:
If a previous project with 500 FPs required 50 man hours for testing, the percentage of testing effort is calculated as:
P = (50 / 500) * 100 =10%
For the current project with a development effort, say 1500 FPs, the testing effort is:
Total Actual Effort, TAE = 1500 * (P/100) = 1500 * (10/100) = 150 man hours.

9. Percentage distribution – Here all the phases of SDLC are divided in parts and assigned effort in %. Like –
Project management 7%
Requirements 9%
Design 16%
Coding 26%
Test (all test phases) 27%
Documentation 9%
Installation and training 6%
Now testing % is further distributed into all testing phases:

OR

10. Use case point estimation method: Use case point (UCP) method is gaining popularity because now-a-days application development is modelled around use case specification. The test case development is normally kicked off after baseline use case. So the various factors in use case give a direct proportion to the testing effort. 
Use case is a document which well specifies different users, systems or other stakeholders interacting with the concerned application. They are named as ‘Actors’. The interactions accomplish some defined goals protecting the interest of all stakeholders through different behaviour or flow termed as scenarios.

UCP Estimation Method in brief
1. Obtain unadjusted actor weight (UAW)
2. Determine unadjusted use case weight (UUCW)  
3. Calculate unadjusted use case points (UUCP) UUCP = UAW + UUCW
4. Determine the technical/environmental factor (TEF)
5. Compute the adjusted use case point (AUCP) AUCP = UUCP * [ 0.65 + (0.01 * TEF)]  
6. Arrive at final effort using a conversion factor Total Actual Effort = AUCP * CF

Conclusion
There can’t be a sole hard and fast rule for estimating the testing effort for a project. There may be different other methods also which can be effectively used for the purpose. It is recommended to add on to the possible knowledge base of test estimation methods and estimation templates constantly revised based upon new findings.

1. Risk Analysis phase
2. Requirements Analysis and Specification phase
3. Design Analysis and Specification phase
4. Source Code Analysis, Unit Testing & Integration Testing phase
5. Validation – System Testing, Functional Testing phase

In this topic we will discuss:

• What is Traceability Matrix from Software Testing perspective? (Point 5)
• Types of Traceability Matrix
• Disadvantages of not using Traceability Matrix
• Benefits of using Traceability Matrix in testing
• Step by step process of creating an effective Traceability Matrix from requirements. Sample formats of Traceability Matrix basic version to advanced version.

In Simple words – A requirements traceability matrix is a document that traces and maps user requirements [requirement Ids from requirement specification document] with the test case ids. Purpose is to make sure that all the requirements are covered in test cases so that while testing no functionality can be missed.
This document is prepared to make the clients satisfy that the coverage done is complete as end to end, this document consists of Requirement/Base line doc Ref No., Test case/Condition, and Defects/Bug id. Using this document the person can track the Requirement based on the Defect id
Note – We can make it a “Test case Coverage checklist” document by adding few more columns. We will discuss in later posts
Types of Traceability Matrix:

• Forward Traceability – Mapping of Requirements to Test cases
• Backward Traceability – Mapping of Test Cases to Requirements
• Bi-Directional Traceability – A Good Traceability matrix is the References from test cases to basis documentation and vice versa.

Why Bi-Directional Traceability is required?
Bi-Directional Traceability contains both Forward & Backward Traceability. Through Backward Traceability Matrix, we can see that test cases are mapped with which requirements.
This will help us in identifying if there are test cases that do not trace to any coverage item— in which case the test case is not required and should be removed (or maybe a specification like a requirement or two should be added!). This “backward” Traceability is also very helpful if you want to identify that a particular test case is covering how many requirements?
Through Forward Traceability – we can check that requirements are covered in which test cases? Whether is the requirements are coved in the test cases or not?

Forward Traceability Matrix ensures – We are building the Right Product.
Backward Traceability Matrix ensures – We the Building the Product Right.

Traceability matrix is the answer of the following questions of any Software Project:

• How is it feasible to ensure, for each phase of the SDLC, that I have correctly accounted for all the customer’s needs?
• How can I certify that the final software product meets the customer’s needs? Now we can only make sure requirements are captured in the test cases by traceability matrix.

Disadvantages of not using Traceability Matrix [some possible (seen) impact]:
No traceability or Incomplete Traceability Results into:

1. Poor or unknown test coverage, more defects found in production 
2. It will lead to miss some bugs in earlier test cycles which may arise in later test cycles. Then a lot of discussions arguments with other teams and managers before release.
3. Difficult project planning and tracking, misunderstandings between different teams over project dependencies, delays, etc
Benefits of using Traceability Matrix

• Make obvious to the client that the software is being developed as per the requirements.
• To make sure that all requirements included in the test cases
• To make sure that developers are not creating features that no one has requested
• Easy to identify the missing functionalities.
• If there is a change request for a requirement, then we can easily find out which test cases need to update.
• The completed system may have “Extra” functionality that may have not been specified in the design specification, resulting in wastage of manpower, time and effort.

Steps to create Traceability Martix:
1. Make use of excel to create Traceability Matrix:

2. Define following columns:

Base Specification/Requirement ID (If any)
Requirement ID
Requirement description
TC 001
TC 002
TC 003.. So on.

3. Identify all the testable requirements in granular level from requirement document. Typical requirements you need to capture are as follows:
Used cases (all the flows are captured)
Error Messages
Business rules
Functional rules
SRS
FRS
So on…
4. Identity all the test scenarios and test flows.
5. Map Requirement IDs to the test cases. Assume (as per below table), Test case “TC 001” is your one flow/scenario. Now in this scenario, Requirements SR-1.1 and SR-1.2 are covered. So mark “x” for these requirements.
Now from below table you can conclude –
Requirement SR-1.1 is covered in TC 001
Requirement SR-1.2 is covered in TC 001
Requirement SR-1.5 is covered in TC 001, TC 003 [Now it is easy to identify, which test cases need to be updated if there is any change request].
TC 001 Covers SR-1.1, SR, 1.2 [we can easily identify that test cases covers which requirements].
TC 002 covers SR-1.3.. So on..

This is a very basic traceability matrix format. You can add more following columns and make it more effective:
ID, Assoc ID, Technical Assumption(s) and/or Customer Need(s), Functional Requirement, Status, Architectural/Design Document, Technical Specification, System Component(s), Software Module(s), Test Case Number, Tested In, Implemented In, Verification, Additional Comments,
Click here to download sample advanced version of traceability matrix.