Software Testing Life Cycle

Software Testing Life Cycle
The software testing life cycle identifies various testing activities and also explains which testing activity needs to be
carried out when. Different phases of the life cycle of software testing have been explained in this article. So, read on.
Software testing life cycle consists of the various stages of testing through which a software product goes and describes
the various activities pertaining to testing that are carried out on the product. Here's an explanation of the STLC along
with a software testing life cycle flow chart. It won't be wrong to call this article, software testing life cycle tutorial.
Introduction to Software Testing Life Cycle
Every organization has to undertakes testing of each of its products. However, the way it is conducted differs from one
organization to another. This refers to the life cycle of the testing process. It is advisable to carry out the testing process
from the initial phases, with regard to the Software Development Life Cycle or SDLC to avoid any complications.
Software Testing Life Cycle Phases
Software testing has its own life cycle that meets every stage of the SDLC. The software testing life cycle diagram can
help one visualize the various software testing life cycle phases. They are
1. Requirement Stage
2. Test Planning
3. Test Analysis
4. Test Design
5. Test Verification and Construction
6. Test Execution
7. Result Analysis
8. Bug Tracking
9. Reporting and Rework
10. Final Testing and Implementation
11. Post Implementation

Requirement Stage
This is the initial stage of the life cycle process in which the developers take part in analyzing the requirements for designing a product.
Testers can also involve themselves as they can think from the users' point of view which the developers may not. Thus a panel of
developers, testers and users can be formed. Formal meetings of the panel can be held in order to document the requirements
discussed which can be further used as software requirements specifications or SRS.
Test Planning
Test planning is predetermining a plan well in advance to reduce further risks. Without a good plan, no work can lead to success be it
software-related or routine work. A test plan document plays an important role in achieving a process-oriented approach. Once the
requirements of the project are confirmed, a test plan is documented. The test plan structure is as follows:
1. Introduction: This describes the objective of the test plan.
2. Test Items The items that are referred to prepare this document will be listed here such as SRS, project plan.
3. Features to be tested: This describes the coverage area of the test plan, ie. the list of features that are to be tested
that are based on the implicit and explicit requirements from the customer.
4. Features not to be tested: The incorporated or comprised features that can be skipped from the testing phase are
listed here. Features that are out of scope of testing, like incomplete modules or those on low severity eg. GUI
features that don't hamper the further process can be included in the list.
5. Approach: This is the test strategy that should be appropriate to the level of the plan. It should be in acceptance
with the higher and lower levels of the plan.
6. Item pass/fail criteria: Related to the show stopper issue. The criterion which is used has to explain which test item
has passed or failed.
7. Suspension criteria and resumption requirements: The suspension criterion specifies the criterion that is to be used
to suspend all or a portion of the testing activities, whereas resumption criterion specifies when testing can resume
with the suspended portion.
8. Test deliverable: This includes a list of documents, reports, charts that are required to be presented to the
stakeholders on a regular basis during testing and when testing is completed.
9. Testing tasks: This stage is needed to avoid confusion whether the defects should be reported for future function.
This also helps users and testers to avoid incomplete functions and prevent waste of resources.
10. Environmental needs: The special requirements of that test plan depending on the environment in which that
application has to be designed are listed here.
11. Responsibilities: This phase assigns responsibilities to the person who can be held responsible in case of a risk.
12. Staffing and training needs: Training on the application/system and training on the testing tools to be used needs to
be given to the staff members who are responsible for the application.
13. Risks and contingencies: This emphasizes on the probable risks and various events that can occur and what can be
done in such situation.
14. Approval: This decides who can approve the process as complete and allow the project to proceed to the next level
that depends on the level of the plan.
Test Analysis
Once the test plan documentation is done, the next stage is to analyze what types of software testing should be carried
out at the various stages of SDLC.
Test Design
Test design is done based on the requirements of the project documented in the SRS. This phase decides whether
manual or automated testing is to be done. In automation testing, different paths for testing are to be identified first
and writing of scripts has to be done if required. There originates a need for an end to end checklist that covers all the
features of the project.
Test Verification and Construction

In this phase test plans, the test design and automated script tests are completed. Stress and performance testing plans
are also completed at this stage. When the development team is done with a unit of code, the testing team is required
to help them in testing that unit and reporting of the bug if found. Integration testing and bug reporting is done in this
phase of the software testing life cycle.
Test Execution
Planning and execution of various test cases is done in this phase. Once the unit testing is completed, the functionality of
the tests is done in this phase. At first, top level testing is done to find out top level failures and bugs are reported
immediately to the development team to get the required workaround. Test reports have to be documented properly
and the bugs have to be reported to the development team.
Result Analysis
Once the bug is fixed by the development team, i.e after the successful execution of the test case, the testing team has
to retest it to compare the expected values with the actual values, and declare the result as pass/fail.
Bug Tracking
This is one of the important stages as the Defect Profile Document (DPD) has to be updated for letting the developers
know about the defect. Defect Profile Document contains the following
1. Defect Id: Unique identification of the Defect.
2. Test Case Id: Test case identification for that defect.
3. Description: Detailed description of the bug.
4. Summary: This field contains some keyword information about the bug, which can help in minimizing the
number of records to be searched.
5. Defect Submitted By: Name of the tester who detected/reported the bug.
6. Date of Submission: Date at which the bug was detected and reported.
7. Build No.: Number of test runs required.

8. Version No.: The version information of the software application in which the bug was detected and fixed.
9. Assigned To: Name of the developer who is supposed to fix the bug.
10. Severity: Degree of severity of the defect.
11. Priority: Priority of fixing the bug.
12. Status: This field displays current status of the bug.
The contents of a bug well explain all the above mentioned things.
Reporting and Rework

Testing is an iterative process. The bug once reported and as the development team fixes the bug, it has to undergo the
testing process again to assure that the bug found is resolved. Regression testing has to be done. Once the Quality
Analyst assures that the product is ready, the software is released for production. Before release, the software has to
undergo one more round of top level testing. Thus testing is an ongoing process.
Final Testing and Implementation

This phase focuses on the remaining levels of testing, such as acceptance, load, stress, performance and recovery
testing. The application needs to be verified under specified conditions with respect to the SRS. Various documents are
updated and different matrices for testing are completed at this stage of the software testing life cycle.
Post Implementation
once the tests are evaluated, the recording of errors that occurred during various levels of the software testing life cycle,
is done. Creating plans for improvement and enhancement is an ongoing process. This helps to prevent similar problems
from occurring in the future projects. In short, planning for improvement of the testing process for future applications is
done in this phase.

Software Testing Life Cycle

Uploaded by

Copyright:

Available Formats

Software Testing Life Cycle

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Testing Life Cycle

Uploaded by

Copyright:

Available Formats

Software Testing Life Cycle

Introduction to Software Testing Life Cycle

Software Testing Life Cycle Phases

5. Test Verification and Construction

9. Reporting and Rework

10. Final Testing and Implementation

11. Post Implementation

Test Verification and Construction

1. Defect Id: Unique identification of the Defect.

2. Test Case Id: Test case identification for that defect.

3. Description: Detailed description of the bug.

7. Build No.: Number of test runs required.

10. Severity: Degree of severity of the defect.

11. Priority: Priority of fixing the bug.

12. Status: This field displays current status of the bug.

Reporting and Rework

Final Testing and Implementation

You might also like