Manual Testing tutorial - part5

Factors Affecting Software Test Estimation, and General Tips to Estimate Accurately:

1) Think of Some Buffer Time
The estimation should include some buffer. But do not add a buffer, which is not realistic. Having a buffer in the estimation enables to cope for any delays that may occur. Having a buffer also helps to ensure maximum test coverage.

2) Consider the Bug Cycle
The test estimation also includes the bug cycle.  The actual test cycle may take more days than estimated. To avoid this, we should consider the fact that test cycle depends on the stability of the build. If the build is not stable, then developers may need more time to fix and obviously the testing cycle gets extended automatically.

3) Availability of All the Resources for Estimated Period
The test estimation should consider all the leaves planned by the team members (typically long leaves) in the next few weeks or next few months. This will ensure that the estimations are realistic. The estimation should consider some fixed number of resources for test cycle. If the number of resources reduces then the estimation should be re-visited and updated accordingly.

4) Can We Do Parallel Testing?
Do you have some previous versions of same product so that you can compare the output? If yes, then this can make your testing task bit easier. You should think the estimation based on your product version.

5) Estimations Can Go Wrong – So re-visit the estimations frequently in initial stages before you commit it. 
In early stages, we should frequently re-visit the test estimations and make modification if needed. We should not extend the estimation once we freeze it, unless there are major changes in requirement.

6) Think of Your Past Experience to Make Judgments!
Experiences from past projects play a vital role while preparing the time estimates. We can try to avoid all the difficulties or issues that were faced in past projects. We can analyze how the previous estimates were and how much they helped to deliver product on time.

------------

7) Consider the Scope of Project
Know what is the end objective of the project and list of all final deliverables. Factors to be considered for small and large projects differ a lot. Large project, typically include setting up test bed, generating test data, test scripts etc. Hence the estimations should be based on all these factors. Whereas in small projects, typically the test cycle include test cases writing, execution and regression.

8 ) Are You Going to Perform Load Testing?
If you need to put considerable time on performance testing then estimate accordingly. Estimations for projects, which involve load testing, should be considered differently.

9) Do You Know Your Team?
If you know strengths and weaknesses of individuals working in your team then you can estimate testing tasks more precisely. While estimating one should consider the fact that all resources may not yield same productivity level. Some people can execute faster compared to others. Though this is not a major factor but it adds up to the total delay in deliverables.

[Project Name] Test Plan

      [Document Version Number]                                                                                 Project Team:

     [Date]                                                                                                                  [Name] [Role]

                                                                                                                                    [Name] [Role]

     Document Author(s):                                                                                                [Name] [Role]

      [Name]                                                                                                                [Name] [Role]

                                                                                                                                    [Name] [Role]

     Project Sponsor:                                                                                             

      [Name]                                                                                                               

I. Introduction

This serves as the plan for testing all software artifacts as well as the reporting of test results.

II. Test Plan

Use the template below to specify the black box test cases you will run on your code.  Every requirement must have a minimum of one test case.  Considering equivalence class partitioning, boundary value analysis, and diabolical test cases, it is likely that each requirement should have several test cases. 

 

Test ID	Description	Expected Results	Actual Results

Where:

·        Test ID is a unique identifier for the test case.  The unique identifier should relate back to the particular requirement the test case is verifying.  For example, if your naming scheme for requirements is numbers, test cases for requirement 3 could have test IDs 3.1, 3.2, etc. Acceptance test cases must end the Test ID with a *. 

·        Description should clearly document the steps that need to be done in order to run the test case.  Write the description specifically, such that any team member can run the test case, even if the author of the test case is not present. 

·        Expected results is a statement of what should happen when the test case is run.

·        Actual results are an indication of whether the test case is currently passing or failing when it is run.  The actual results could be recorded simply as “Pass” or “Fail.”  However, it is also helpful to describe what happened in cases where a test case fails. 

Ultimately, your customer should agree to the test case.  When test cases are written so specifically, often requirements understanding is enhanced. 

III. Testing Deliverables

Specify the planned testing deliverables which may include:

• Test Design Specification

• Test Case Specification

• Test Procedure Specification

• Test Log

• Test Incident Report

• Test Summary Report

• Test Input and Output Data

IV. Environmental Requirements

Specify the environmental needs for conducting tests:

• Hardware, communications and system software, other supplies, etc.

• Level of security

• Testing tools

V. Staffing

Specify testing responsibilities, staffing and training needs.

VI. Schedule

Specify testing schedule.

VII. Risks and Contingencies

Specify any potential risks and plans for mitigating, addressing and/or resolving those risks.

VIII. Approvals

List any approvals / signatures required to sign off on test results.

IX. Document Revision History:

Version	File version number.
Name(s)	Name of individual(s) responsible for the change.
Date	Date of change.
Change Description	Description of the changes made to the file.

Test case Template:-

Traceability matrix:-

.No	Requirement ID	Test cases	Requirement version	Defects
1	REQ_1234	TC001, TC002, TC003	V 1.0.0

Project Name:
Project Manager Name:
Project Description:

Test result

Test Report
Iteration/ Cycle
EXECUTED	PASSED	25
	FAILED	0
	(Total) TESTS EXECUTED (PASSED + FAILED)		25
PENDING			0
IN PROGRESS			0
BLOCKED			0
(Sub-Total) TEST PLANNED			25
(PENDING + IN PROGRESS + BLOCKED + TEST  EXECUTED)
DEFERRED			0