Software Testing Life Cycle

Software Testing Life Cycle is associated with the following phases:

1. Test Planning
2. Test Development/Design
3. Test Execution
4. Result Analysis
5. Bug Tracking
6. Reporting

1. Test Planning

A Test plan is defined as the strategic document, that describes the
whole procedure how to carry on the testing on the entire application effectively, efficiently and with a greater optimization.

Content of Test Plan:

i. Scope and the objective of the test plan.
ii. Areas of the functionalities to be tested.
iii. Areas of the functionalities not to be tested.
iv. Resource planning.
v. Scheduling.
vi. Test Deliverables.
vii. Test Strategy.
viii. Testing terminology and the defect metrics definition.
ix. Areas of testing to be automated.
x. Evaluation of the automated tools and the list of the automated tools used.
xi. Entry and Exit criteria
xii. The details of the author, reviewer and approval authority with respect to the test
plan document.
xiii. Risks and contingencies plan.

Scope: It defines the portion of the project to be addressed and focused by the test plan.

Objective: Which defines the testing services for a specific portion of the project
as per the scope.

Areas of the functionalities to be tested: This field describes the major areas of the functionalities interns of modules that are to be tested as per the scope.

Areas of the functionalities not to be tested: Some of the functional areas should not be tested for the following reasons:

1. If the functionalities are out of scope.
2. If the functionalities are not covered by the test strategy provided by the customer.

Resource Planning: It is the process in which what testing professional does what work, is decided. In other words, tasks are mapped with the man power of testing domain is described under this section.

Scheduling: This field details the information that is associated with the time factors of the task. In other words duration of the task, starting date of the task and the ending date of the task is defined here.

Test Deliverables: This means list of all the corresponding documents that are basically originated from testing department or testing effort some of the deliverables are given below:

Review Report
Test Report Document (TRD)
Defect Profile Document (DPD)
Detailed Test Case Document (DTCD)
Master Test Case Document (MTCD)
Function Point Document (FPD)
Test Metrics Document
Test Matrix Document
Periodic Project Report (PPR)
Software Delivery Note (SDN)
Certification Document.

Test Strategy: Test Strategy means what and all the activities that are associated with testing in terms of kinds of testing, methods of testing, levels of testing, types of testing and ways of testing are described.

Note: In the organization various documents are produced under the classification.
Organizational level, project level, and module level documents. Test process document or test strategy document belongs to organizational level document where as test plan document is project level document and test case document is module level document.

Testing terminology and the defect metrics definition: All the terms that belong to testing domain are listed out here. As there are various defects that are to be addressed with various expressions will be defined here based on the degree of seriousness of the defect.

Areas of testing to be automated: Having carefully analyzed the automation testing scope one has to list out all the possible testing efforts that can be tested with the automated tools. In other words the portion of testing to be automated and the portion not be automated can be detailed under this section.

Evolution of tools: Depends on the features of the application and the transactions of the application to tested after, careful evolution the automation experts must select the appropriate automated tool and list them out under this section.

Entry Criteria: The criteria that are required to initiate/start the testing activity can be detailed here as entry criteria.

Exit Criteria: The criteria that is required to terminate testing activities can be detailed here as exit criteria.

The details of the author, reviewer and approval authority with respect to the test plan document: For every document there are three roles involved in terms of author (who actually creates it), reviewer (who verifies it), and approval (who finalizes it). In order to carry on the respective responsibilities on the document. The details of all these roles will be given under this section.

Author – TE, Review – Peer reviewer, Approval – BA

Risks and contingencies plan: The test managers carefully must access all the risks in advance and be prepared with the solutions to resolve the risks if at all they shoot up in terms of contingency plan.

Note: The test plan is usually prepared by either SQM or Quality Lead (QL). Project plan is prepared by project manager. Project plan can be input or base document for the preparation of test plan document.

2. Test Development/Design

This stage is meant for developing a strategy for testing specially to test a specific functionality in a detailed fashion, in terms of test case document preparation. Hence the test engineers prepare the test case document in this phase.

The preparation of test case document is always done with the help of template which is given below:

i. Test objective/test scope
ii. Test scenario
iii. Test procedure
iv. Test cases
v. Test data

Note: There will be multiple test case documents prepared for a single project most often at the module level.

i. Test objective/scope: This section details what portion of the application is tested with the help of this test case document.
ii. Test scenario: This section details the situation in which the testing is carried on. In other words the specific context has to be described in which test case document can be executed.
iii. Test procedure: Any specific functionality is plans to be tested in such a way that the look and feel of the functionality is tested under GUI testing, the positive behavior is tested under the positive testing and negative behavior under negative testing with the help of test cases like GUI, positive and negative test cases.
iv. Test Cases: This section details the list of various test cases in terms of the corresponding test steps. The information described in a tabular format under the classification of GUI test cases, positive and negative test cases.

When test cases are drafted the test engineer must follow some of the standards as given below:

a. It should be précised and to the point.
b. It must be clear and easy to understand.
c. It must be in terms of instructions rather than statement.
d. It must reproducible and reusable.
e. It can use the hyper linking technique to fetch the test data with which testing can be proceeded.

v. Test Data: It is defined as the data that is utilized at the time of execution of the test cases to test a specific functionality.

3. Test Execution

This phase is meant for implementation of the test strategy that is developed in the previous phase – test design. In other words the test case document prepared will be executed on the developed and released functionality.

4. Result Analysis

It is the process of analysis in which the result is determined. Usually the test results are expressed in terms of pass or fail.

In the process of result analysis when the expected value is compared with the actual value and if they are matched with each other the result is expressed in terms of “pass” otherwise i.e., if they are mismatched then result “fail”.

Pass means the requirement is justified properly, on the other hand fail means there is a deviation from the requirements.

5. Bug Tracking

Soon after the test execution is over and the results are analyzed, all the failed cases are mostly considered as defects. These defects are not only identified they are basically tracked into a specific document known as defect profile document. Hence this phase is meant for preparing the defect profile document.

6. Reporting

The defect profile document that is prepared in the previous phase will be sent by the test engineer to the development team under the process known as reporting; this is also referred to as bug reporting process.

Apart from defect profile document (DPD) the test engineer prepare the high level document known as Test Report Document (TRD). This document will be sent to the high level management and customer (if he requires). In order to let them know the status of testing and the stability of functionality. This document contains the high level description of status and stability with the pictorial representation in order to make them understand clearly. Hence the reporting phase deals with two documents that is DPD and TRD.