Testing Life Cycle
(Written by M.Vilson, [email protected])
Though it may vary from organization to organization, a testing life cycle should always be a part of an organization’s software development life cycle in order to avoid major defects and complications with the end product. The testing life cycle is the various activities and stages of testing that a software product goes through before it is released. The stages of the testing life cycle are often similar to those of the software development life cycle (SDLC). They are depicted in the image below and include the following:
- Requirement Stage
- Test Planning
- Test Analysis
- Test Design
- Test Verification and Construction
- Test Execution
- Result Analysis
- Bug Tracking
- Reporting and Rework
- Final Testing and Implementation
- Post Implementation
In the first stage of the testing life cycle developers and testers usually analyze the requirements used in designing the product. Testers are especially useful in this stage because they tend to see things more from the users point of view. Often, this group will hold formal meetings in order to document the test requirements discussed. These requirements will likely be uses as part of the software requirements specifications for the test.
Test planning is critical in increasing a development team’s chances in producing high-quality software. Once the requirements of the project are examined, a test plan is created and documented. In this stage the software test plan (STP) document is written. The STP provides the scope of testing, testing approach, required resources, schedule, etc. It identifies the items and features being tested, the type of testing being utilized, team members responsible for testing, required resources, and associated risks.
Once the test plan is complete, the next stage in the testing life cycle is test analysis. In this stage, the team analyzes the types of software testing that is to be used. Decision on whether to us manual and/or automated testing are typically made during this stage. Another aspect of this stage is the development of test cases. Test cases should be prepared based on boundary conditions as well as positive, negative, and real world scenarios. Some important outcomes of this analysis it to make sure that all requirements are covered by at least one test case, determine what to automate (if anything at all), review documentation, and define areas of stress and performance testing.
In this stage of the testing life cycle, the test is designed based on the requirements documented in the SRS. Sometimes, an end-to-end checklist that covers all of the features of the project is created. The various software modules and the paths connecting them are identified as well. Decisions on manual vs. automated testing are finalized. If any parts of the test are to be automated, the different test paths are identified, and any necessary scripts are written. If necessary, test plans and cases are revised, test data is prepared, and the criteria for risk assessment are developed. The team also sets the standards for unit testing and the pass/fail criteria, finalizes the testing schedule, and prepares the testing environment.
Test Construction and Verification
In this stage of the testing life cycle, test plans and design, automated scripts (if applicable), plus any stress and/or performance test plans are completed. Upon completion of units of code, the testing team assists the development team with testing and sometimes integrating those units and reporting any bugs that are found.
In this stage, the planned test cases area executed. This usually begins with unit testing. Once the unit testing is complete, functionality testing is done. Top level testing is usually performed to locate failures and bugs, which are reported to the development team so they can provide any possible workarounds.
The results of testing must be analyzed. If a bug is found and fixed by the development team, the test case is rerun. After a successful execution of the test case, the team should compare the actual values to the expected values before declaring the result as pass/fail.
Keeping track of bugs is very important in a testing life cycle. It is a good idea for a project team to follow a specific bug life cycle. One document that is sometimes created during this stage is the Defect Profile Document (DPD). This document keeps developers informed about defects and may assist in the prevention of future bugs. It usually contains the following information:
- Unique identifier for the defect
- Test case where the defect occurred
- Date when defect was found and reported
- Detailed description of the defect
- Name of person that found the bug
- Version of the software in which the bug was found (and fixed if applicable)
- Name of the person that the defect was assigned to
- Severity of defect
- Priority of defect
- Current Status
Reporting and Rework
Testing should always be an iterative process. This means that once a bug is reported and fixed, it must go through the testing process again to assure that an adequate resolution was found. Regression testing is often included as a part of this stage.
Final Testing and Implementation
This stage of the testing life cycle usually focuses on the remaining levels of testing. This may include acceptance, stress, load, performance, and recovery testing. Even after the quality team determines that the product is ready and that the software can be released for production, some teams perform an additional round of top level testing. The software is verified based on conditions specified in the SRS. All documentation is usually updated if necessary.
In this stage of the testing lifecycle, the testing process is evaluated and lessons learned should be thoroughly documented. This should be done after the testing cycle of all projects in order to prevent future occurrences of similar problems encountered in the current project. Planning for enhancements and improvements should be an ongoing process.