Software Test Life Cycle or the Software Test Process
The Software Test Life cycle addresses the Testing aspect of the Software Development Life Cycle. It includes all activities from Test Planning, writing test cases, test execution to QA sign-off.
Many organizations have a team that is independent of the Development team or a part of the Development Team i.e. they report to the same Manager. Irrespective of this, a Test Process is followed and the Test Life Cycle is described below. The process could be tailored in some ways depending on the organization.
The Software Testing Life Cycle begins with understanding the scope of Testing or the Test Effort for a Project. This is captured in the Test Plan and answers questions like What will be tested, How much – breadth and depth or scope , How, by whom and when? The Plan is driven by the time available and the number of resources (People and machines) required.
There are five phases in the Software Test Cycle:
1. Test Planning and control
2. Analysis and Design
3. Implementation & Execution
4. Evaluating Exit Criteria & Reporting
5. Test Closure Activities
These are not to be confused with the Software Development Life Cycle. Remember, Testing is a sub-process in the overall Software Development Life Cycle. The Test Life Cycle helps streamline only the testing-related activities.
1. Test Planning & Control phase:
In this phase, the Master Test Plan and other Test Plans are created in detail. IEEE 829 is the standard template on which most templates are based on. Most organizations have a standard format which is tailored from the IEEE 829.
Test Planning involves planning for the various activities within the testing phase. Determining what is going to be tested, how (manual or automated), the breadth and depth of testing(scope) and who or which resource will conduct the testing all form part of this phase. At the end of this phase, a well-defined Test Plan(the System Test Plan with the MS Project Plan for date/ schedule, resources) is the outcome.
The Test Plan addresses the following and more:
Type of Testing: System or Functional, UAT, Performance
Scope of testing – Features that will be tested, Features out of scope
Test Environment: Hardware, Software needed for the Test Environment, Test Data
Resources: Testers who will be involved
Schedule: The dates when each activity will start and complete and dependencies if any
Regression Tests
Automation effort if any
Review & Sign-off of test artefacts from Stakeholders – PM, BA, Customer, Development Lead etc
Number of Test Cycles planned
Tools for Defect Logging, Automation and any other
Configuration Management and QA Builds
Sanity Test & Criteria for QA drop-off
Defect Life Cycle
Risks – Software Risks, Project risks (Test Environment not ready, unable to procure a license, resource quits)
What to do when deliverables to Testing are delayed
Prioritization of tests during time crunch based on Risk
Test Control:
This is to address what to do when actual progress does not match with the estimates when things go wrong etc
2. Test Analysis and Design:
In this phase, the Requirements document, Functional Spec, Design Documents etc are reviewed and understood in detail and tests are designed. Coming up with Test Conditions, Test Cases, Test Steps are all part of this phase. Designing and prioritizing test cases, getting them reviewed by the BA and Development to ensure sufficient test coverage, designing the Test Environment, determining the Test data are all part of this phase.
3. Test Implementation and Execution:
This phase is what most people think of as testing, where the software is actually tested. Sanity tests are conducted before accepting the Build for testing. If the sanity checks fail, testers may not be able to proceed with testing. Tests are conducted based on test cases and a comparison of expected and actual results is done. If they match, the test is passed. Else the discrepancy is marked as Failed and logged as a defect in the defect tracking system.
Defects follow the Defect Life Cycle defined by the organization or tailored for the Project. Some defects are fixed, other s might be rejected because it is too difficult to fix and will be addressed in the next release, it might be a Duplicate issue or it might not be an issue(the test case was incorrect).
When a defect is fixed, tests are run to ensure the fix has not broken something else (Regression testing) and the defect has been fixed(Confirmation testing).
4. Evaluating Exit Criteria and reporting:
In this phase, the Test Manager checks if all the tests that were planned could be conducted and the test cycle is complete. And if further testing is necessary. A Test Summary report for stakeholders is the outcome of this phase. The Test Summary report is usually based on IEEE 829 Test Summary template and will say – planned vs actual activities, variances and why, defects found, fixed & not fixed, test environment etc. Unfixed defects will make it to the ‘known issues’ report.
5. Test Closure:
In this stage, Testing is officially complete. Making sure documentation is up to date, archiving the test environment, lists of defects and metrics and lessons learnt are all part of this phase.
