Testing is a critical process in every industry that comes under software development and most QA teams will be using most, if not all, of the software testing life cycle phases.
In this article, we will cover:
- What is the software testing life cycle and what phases make up the STLC?
- Entry and Exit Criteria in the STLC
- Best Practices in Software Testing Life Cycle
- Software Testing Life Cycle vs Software Development Life Cycle
- The Defect Life Cycle
What is the Software Testing Life Cycle (STLC)?
The software testing life cycle, also known as STLC, is a multi-step sequence of phases that are conducted during the testing process to ensure that software quality goals are met and that clients receive a fully functional product – with no bugs or faults.
Each phase has different goals and deliverables, but not all phases have to be conducted during the testing process – this depends on the nature of the software or product.
What is the role of the STLC?
Even with the most talented, highly skilled team of developers, mistakes can still happen as a result of human nature.
The role of the software testing life cycle is to identify any mistakes that have been made and find solutions for them, helping to maintain the quality of every piece of software produced and ensuring that the project requirements are met.
STLC Phases
The software testing life cycle consists of six main phases, each of which involves specific actions designed to ensure that a high standard of performance and quality is achieved.
The six main phases of the STLC are:
- Requirements Analysis
- Test Planning
- Test Case Development
- Environment Setup
- Test Execution
- Test Cycle Closure
Requirements Analysis
The requirements analysis phase is where the QA team studies the business requirements specification (BRS) document to identify the requirements from a testing perspective.
This might require the team to communicate with stakeholders to understand the requirements in further detail. Alternatively, a mitigation plan can be created if any requirements are not testable.
Activities in Requirements Analysis
- Identify the types of tests to be performed and assigned to the development
- Gather details about testing priorities and focus
- Prepare the Requirement Traceability Matrix (RTM)
- Identify test environment details where testing is supposed to be carried out
- Conduct automation feasibility analysis (if needed)
Deliverables of Requirements Analysis
- RTM: This document maps and traces requirements proposed by the client with test cases to ensure that every requirement has an associated set of test cases against it.
- Automation feasibility report (if applicable): This report would be produced as a result of analysing the project, working out what screens have components that can have automation tests written against them, the complexity of writing the automation tests, whether the test cases handle large amounts of test data among other factors.
Test Planning
The test planning phase is usually conducted by the QA manager, it involves creating the test plan and strategy documents along with determining the effort and cost estimates for the entire project.
Activities in Test Planning
- Preparation of the test plan/strategy document
- Selecting any tools required during the testing
- Test effort estimation
- Training requirement
Deliverables of Test Planning
- Test plan document: The ISTQB defines a test plan as “Test Plan is A document describing the scope, approach, resources, and schedule of intended test activities.”
- Test effort estimation document: This document will include the estimations of how long it will take to complete the testing tasks.
Test Case Development
The test case development phase involves the creation of test cases for each unit and any test scripts once the test plan is ready. These test cases cover the validation, functionality and points of verification described in the Test Plan.
Activities in Test Case Development
- Preparing the test cases and any automation scripts (if required)
- Enumerating the possible actions of the users and their objective
- Setting the priorities of test conditions
- Selecting the condition under which testing will take place
- Documenting any test conditions
- Verifying and correcting the test cases based on modifications
Deliverables of Test Case Development
- Test cases: This is a set of actions that test a particular piece of functionality of the software project.
- Test data: The input is given to a software program during the execution of the test cases.
- Test automation script: These are scripts created by automation engineers with the idea of them being run frequently to reduce the reliance on manual testing.
Test Environment Setup
The test environment consists of elements that support test execution, the setup of the testing environment is done based on the hardware and software requirement list. The test environment should mimic the production environment as closely as possible to uncover any environmental or configuration related issues. This phase can go in parallel with the Test Case Development phase.
Activities in Test Environment Setup
- Analysing the requirements and preparing the list of required hardware and software to set up the test environment
- Setting up the test environment
- Executing a smoke test on the test environment to validate the readiness and stability of the test environment
Deliverables of Test Environment Setup
- The test environment is ready for the test execution phase
- Smoke test results
Test Execution
The test execution phase is the execution of test cases that have been created as a result of the test case development phase. This is done by the testing team where bugs are reported back to the development team for them to fix with retesting to be performed at another time depending on the software development methodology that the project is following.
Test Execution Activities
- Execution of the test cases
- Recording results in the companies test case management tool
- Reporting any defects for any failed test cases
- Retesting any defects after these have been fixed by the development team
Deliverables of Test Execution
- Report on any defects that have been raised during the test execution phase
- Overall summary of the test case results
Test Cycle Closure
The test cycle closure phase involves the analysis and evaluation of the whole testing cycle to work out what worked and what didn’t.
The QA team meets to evaluate the cycle completion criteria based on test coverage, quality, time, cost, software and business objectives. The bug and test case reports are analysed to identify the distribution of defects based on severity and type.
After completion of the test cycle, the test metrics and test closure report will be created.
Test Cycle Closure Activities
- Preparation of the test closure report
- Evaluate the cycle completion criteria (based on test coverage, quality, time, cost, software and business objectives)
- Prepare test metrics based on the above parameters
Deliverables of Test Cycle Closure
- Test metrics
- Test closure report – a document that gives a summary of all the tests conducted during the software development life cycle, it also gives a detailed analysis of the bugs removed and errors found
What are entry and exit criteria in STLC?
Entry Criteria: Entry criteria in the STLC are the prerequisites that must be met before the next phase can be started. For some phases of the STLC, the entry criteria can sometimes be the exit criteria from a previous phase, such as test plans, test environments and test cases and test data.Exit Criteria: For exit criteria, these are usually a set of conditions that need to be met before the phase can be completed. You need to have entry and exit criteria for all phases of the STLC and you should not enter the next phase until all the exit criteria from the previous phase are met.
Table of STLC Phases with Entry and Exit Criteria
| Phase Name | Entry Criteria | Exit Criteria |
|---|---|---|
| Requirement Analysis | Requirements document Acceptance criteria defined | • Signed off requirement traceability matrix • A signed off automation feasibility report |
| Test Planning | Requirements document Requirements traceability matrix Automation feasibility report | • Approved test plan/strategy document • Test effort estimation document signed off |
| Test Case Development | Requirements document Requirements traceability matrix Test Plan | • Reviewed and signed off test cases and/or test scripts • Reviewed and signed off test data |
| Test Environment Setup | Production environment design and documentation is available Environment set-up plan is available | • Environment setup is working as per plan and checklist • Test data setup is complete • Smoke test results are successful |
| Test Execution | Test plan document is available Test environment is ready Test cases are available Test scripts are available | • All test cases and scripts planned are executed • Any defects have been logged and closed down |
| Test Cycle Closure | All testing has been completed Test results are available A list of all defects is available | • Test closure report is signed off by the client |
Best Practices in the Software Testing Life Cycle
Several best practices apply to software testing, one being to adopt the ‘test early test often’ approach. This testing strategy helps get the QA team involved as early into the development process as possible so that they have the chance to raise any issues at the earliest opportunity.
This helps to reduce costs as the later into the project issues get found the more expensive they are to fix. This best practice can be found in an iterative development methodology which is arguably the preferred choice for many IT companies today.
Another best practice in the software testing life cycle is to adopt the continuous testing approach, this is the process of executing tests as part of the delivery pipeline to get faster feedback on any potential issues as soon as possible.
Another strategy is to conduct the right types of testing based on the requirements, this should eliminate a large number of redundant tests, increasing the time the QA team can spend testing the feature of the product which should reduce the number of issues found at a later stage.
Another phrase is the Pesticide Paradox, this comes from the idea that if pesticides are frequently used on crops, there comes a time when the insects begin to develop a certain kind of resistance, making the pesticides ineffective.
This concept can be applied to testing as well if the tester runs the same tests again and again, eventually, these tests will be ineffective because no more defects will be found.
To resolve this, new test cases should be created at regular intervals to help identify new issues. This is another best practice to follow when testing software.
STLC vs. SDLC: What’s the difference?
The Software Testing Life Cycle is a phase of the Software Development Life Cycle, which can be carried out as part of the Software Development Life Cycle or alongside its various other phases depending on the methodology being used.
The Software Testing Life Cycle defines the phases or activities that are carried out to improve the overall quality of the product.
The Software Development Life Cycle (or SDLC) defines all the phases that are involved in the complete software development process (which includes the testing of the product).
The SDLC aims to produce a high-quality software product that meets the expectations of the client, the STLC ensures the product works as it is expected to.
The phases in the SDLC are:
- Requirements Gathering
- Design the software
- Build the software
- Test
- Deployment
Here are some of the key differences between the SDLC and the STLC:
SDLC
- Parent process
- Focuses on meeting user requirements and developing a useful product
- All phases must be completed before testing
- Aims to supply users with a quality product
STLC
- Child process
- Focuses on testing the product to ensure it is working as intended
- STLC usually begins after the main development phases are completed
- Aims to find bugs to report to the development team for fixes
If the SDLC is followed it should ensure that the system requirements are traced back to the business requirements, much like the STLC every phase in the SDLC has a specific deliverable, entry and exit criteria.
These deliverables are understandably different from the deliverables described in the STLC phases, examples are a development plan is created as part of the requirements gathering phases in the SDLC whereas in the STLC the QA team will create a system test plan.
Defect Life Cycle
The defect life cycle describes the different states a bug can be in through its entire life, it can also be referred to as the bug life cycle.
The defect life cycle also involves the classification of the different priorities and severity of the bugs identified by the testing team.
Defect priority refers to the order in which defects should be resolved (from the QA team’s perspective) whilst defect severity classifies the impact of the defect and the complexity of the fix (from the development team’s perspective).
Defect Life Cycle States
- New: The defect has been raised but hasn’t been validated yet.
- Assigned: A member of the development team has been assigned the defect.
- Active: The defect is now being investigated by the development team.
- Test: The defect has been fixed and is now ready for the QA team to verify.
- Reopened: The proposed fix has been rejected by the QA team so the issue remains unresolved.
- Verified: The defect has been fixed and verified by the QA team.
- Closed: If the defect no longer exists, the state of the bug is fixed and set to ‘closed’.
- Rejected: If the defect has already been raised, not reproducible or not a defect then the bug can enter a ‘rejected’ state
- Deferred: This is when the bug has been prioritised for the next release.
Defect Priorities
The QA team typically sets the priority status when the defect is brought to the attention of the development team and is based on the end user’s requirements.
Low Priority: The defect fix is not of an urgent nature and can be delayed until more important fixes are completed.
Medium Priority: The development team should fix the bug in subsequent builds.
High Priority: The impact of the bug on the software is substantial and should be addressed immediately.
Urgent Priority: The product cannot be used until the defect is fixed so it should be resolved urgently.
Defect Severity
Defect severity is based on how severely the defect impacts the functionality of the software and how complex it is for the development team to resolve.
- Critical Severity: The defect affects the core functionality of the software and the QA team cannot continue testing the product until it is fixed. An example of a defect that is of critical severity is one that causes the product to crash often.
- Major Severity: The defect affects core functions considerably but the test team can continue testing other aspects of the software without this one first having to be fixed.
- Medium Severity: The defect impacts just one screen or one specific function but does not actually stop the function from working.
- Low Severity: The defect has no impact on the product’s functionality and is likely to be purely cosmetic. Fixes ar4e likely to improve UX and UI.
Importance of the Software Testing Life Cycle
Any software development project aims to produce products that are of the best possible quality and the test team can help this in many ways.
The first is adopting the STLC and ensuring that each phase is defined at the start of the project – defining the entry and exit criteria for each phase and ensuring the major stakeholders within the project are aware of these.
If the requirements are not properly defined before the end of the requirements gathering phase, this will have a detrimental effect on the quality of the product at the end – as either the QA team or development team could be missing key pieces of information.
If the company is using the STLC as part of the SDLC – the objective is to produce a product of the highest quality, and following these provides the best opportunity of doing this.
Adopting several testing best practices such as the ‘test early test often’ approach will greatly reduce the number of issues raised at a later stage of the project, while also being aware of the pesticide paradox is critical for ensuring that the quality of test cases remains high and the QA team time remains effective.
Want to learn more about our approach to software testing?
Here at Coderus, we approach QA and testing with an agile methodology – executing all phases of the QA life cycle process. We hold ourselves to the highest industry standards and endeavour to create a flawless user experience for all users, in every project we work on.
Get in touch with us today to learn more about how our expertise can take your software project to the next level.
