Software Test Estimation

There are various methods for estimating testing effort.

Here are few testing efforts that we can discuss.

1) Work Break Down Structure:
This method is a bottom up estimation technique.

Here the testing activities are broken down to smallest possible tasks as is technically feasible. The efforts are estimated for each tasks. The efforts are then summed up to get total effort for the project.

PS: If any one has more details on this, please feel free to add more information.

2) Three point estimate:

In this type of estimation method, the estimator have to specify pessimistic, optimistic and most probable values for each tasks. Estimation is then done using the formulae:

{(Most probable value * 4) + (Pessimistic Value + Optimistic value)} / 6.

The efforts are then summed up to get total effort.

PS: If any one has more information on how pessimistic, optimistic and most probable values are decided, please let us know.

3) Task complexity based estimation

The tasks are classified into simple, complex and averege tasks. Efforts are then calculated for these tasks. These efforts are summed up to get final estimation effort.

4) Use case point method of estimation:

Consider these tables:

Unadjusted Actor Weights (UAW):

Actor No of UC Factor UAW

B2CUser 15 2 30

Subscribers 13 2 26

Admin Users 4 2 8
____________________________________
Total UAW= 64
____________________________________

Here, those who interact with the system are known as actors.
Depending on the complexity of the actor, factor are assosicated with each of them.
Number of use cases and factors are multiplied to get UAW i.e Unadjusted Actor Weights.

UAW's for each actor are summed up, to get total UAW.

Unadjusted Use Case Weights (UUCW):

UseCase Type Factor Reason

Login C 15 Server

Support Request VC 20 External System Query

User Creation A 10

Support Req Mgmt S 5 Code reuse

Fix Notification S 5 Trivial
_________________________________________________
Total UUCW = 55
_________________________________________________
Here S = Simple, A = Average, C = Complex and VC = Very Complex

Here, depending on the usecase, it is classified as simple, average, complex and very complex.
Factor's are associated with each use case depending on the complexity.
These factors are summed up to get the total UUCW i.e Unadjusted Use Case Weights.

Now
Unadjusted Use Case Point,
UUCP = UAW + UUCW
=> 64 + 55
=>119

Therfore UUCP = 119.

Now, we will calculate AUCP, i.e Adjusted Use Case Point

AUCP = UUCP * [0.65 + (0.01 * TEF)]

What is this TEF in the equation?
TEF is called as Technical Environment Factor.
We will now calculate this technical environment factor.

Consider the below table:

Factor Description Value Weight Extended Value

T1 Test Tools 5 3 15

T2 Doc Inputs 5 5 25

T3 Dev Env 2 1 2

T4 Test Env 3 1 3

T5 Test Ware Reuse 3 2 6

T6 Distributed System 4 4 16

T7 Performance Objectives 2 1 2

T8 Security Features 4 2 8

T9 Complex Interfacing 5 2 10
___________________________________________________________
Total Technical Environment Factor= 87
___________________________________________________________

Now,
AUCP = UUCP [0.65 + (0.01 * TEF)]
=> 119 [0.65 + (0.01 * 87)]
=> 180.88

Therefore AUCP = 180.88

There will be a conversion factor associated with each kind of testing. (I am not aware of conversion factor except for the testing, that has been used in this example. If any one is aware of conversion factors for different types of testing, please let me know)

Final Effort = AUCP * Conversion Factor
=> 180.88 * 13
=> 2351.44

Project complexity needs 15% of total effort and 10% spent in coordination and management activity.

Project complexity = 15% ( 2351.44) = 352.716
Coordination and management = 10% (2351.44) = 235.144

Therefore
Total effort= 2351.44 + 352.716 + 235.144

367 Man Days.

Therefore, Total effort = 367 Man Days

Software Test Metrics

We come across different kinds of software testing metrics during testing which are very helpful during test strategy and test planning .

Below are few software testing metrics.

1) Test coverage metrics :

(No of requirements covered for test case development) / (Total no of requirements)

2) Test case design productivity :

(No of test cases developed) / (Engineering day)

Here 1 engineering day is 8 hours.

Standard value for test case design productivity is 25 to 30.

3) Test case execution productivity :

(No of test cases executed) / (Engineering day)

Standard value for test case execution productivity is 30 to 35.

Test effort estimation

1) Schedule variance = ((Estimated Schedule – Actual Schedule)/Estimated Schedule)) * 100

2) Effort variance = ((Estimated effort – Actual effort)/Estimated effort)) * 100

Defect metrics

1) Defect prevention ratio :

((Sum of all review defects) + (Number of unit test defects) ) / ((Numerator) + (Sum of defects in integration and system testing))

Acceptable value for defect prevention ratio is 0.85

2) Defect detection ratio :

((Sum of all review defects) + (Sum of integration testing and system testing defects)) / ((Numerator) + (Sum of user acceptance testing defects))

Acceptable value for defect detection ratio is 0.98.

Any suggestions for improvements is appreciated.

Best Regards

Narasimha Murthy.

Test Strategy and Test Planning

Test strategy and Test planning coexists in testing world.

Test strategy is done during design phase of a project. You already have a requirement, on which you can base your test strategy.
Test plan is done during the construction phase. You have requirements, strategy and design as inputs to your test plan.
The prototype of screen layouts are used to develop a major percentage of test cases during construction. When construction is done, the test cases are modified to suit the actual application after complete development.

Test Strategy

What are the contents of a test strategy document?

The test strategy document contains test cases, test conditions, test environment, a list of related tasks, pass/fail criteria and risk assessment.
The test strategy document is a formal description of how a software product or application will undergo the test.

What is the strategy document developed for?

It is developed for all levels of testing as required.

How a test strategy is written and who writes it?

Test team that analyses the requirements, writes the test strategy and reviews the plan with the project team.

How do you create a test strategy?

The test strategy is a formal description of how a software product will be tested. A test strategy is developed for all levels of testing. The test team analyses the requirements, writes the test strategy, and reviews the plan with the project team. The test plan may include test cases, conditions, and the test environment, a list of related tasks, pass/fail criteria and risk assessment.

Contents of Test Plan

Brief description of system.
Types of test:
Unit testing
Integration testing
Performance testing
Load/Stress testing
UAT
What to test (depends on the criticality)
What not to test
Who tests what
Tools used to testing
Schedule for testing
Acceptance Criteria
Risks
Assumptions
Test environment
Test data

Contents of Test Strategy:

Who does the testing?
What to test
When to test – Like when the module would be delivered to the test team.
Where to test – Test environment
How to test – Requires details about tools involved
Why to test
How do you know have done the testing.

Best Regards
Narasimha Murthy

PS: Please feel free to post comments and ask questions.