Software Testing Life Cycle (STLC)

October 12, 2020
Software Testing Life Cycle

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 phases of the software testing life cycle (STLC).

In our article, we will be covering:

  • What is the software testing life cycle and what phases make up the STLC?
  • Entry and Exit Criteria in the STLC
  • Best Practices in the STLC
  • 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 sequence of phases that are conducted during the testing process to ensure that software quality goals are met. Each phase has different goals and deliverables, but not all phases have to be conducted during the testing process – depending on the nature of the software or product.

The 6 main phases of the STLC are:

  1. Requirements Analysis
  2. Test Planning
  3. Test Case Development
  4. Environment Setup
  5. Test Execution
  6. Test Cycle Closure

STLC Phases

Requirements Analysis

This phase is where the QA team studies the business requirements specification (BRS) document to identify the requirements from a testing perspective and identify the testable requirements. This might require the team to speak to stakeholders to understand the requirements in further detail or 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 which 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

This 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

This 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 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

  • Test Environment ready for test execution phase
  • Smoke test results

Test Execution

This 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

For the test cycle closure phase, this 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: Is 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?

In every phase of the STLC, there are prerequisites which must be completed before starting that specific phase, this is defined as Entry Criteria. 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.

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 NameEntry CriteriaExit Criteria
Requirement AnalysisRequirements document Acceptance criteria defined• Signed off requirement traceability matrix
• A signed off automation feasibility report
Test PlanningRequirements document Requirements traceability matrix Automation feasibility report• Approved test plan/strategy document
• Test effort estimation document signed off
Test Case DevelopmentRequirements document Requirements traceability matrix Test Plan• Reviewed and signed off test cases and/or test scripts
• Reviewed and signed off test data
Test Environment SetupProduction 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 ExecutionTest 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 ClosureAll 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 approach of ‘test early test often’. This approach helps get the QA team involved as early into the development process as possible so that they have more of an opportunity to raise any issues at the earliest opportunity which costs less to resolve. 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 IT companies today.

Another best practice 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 when the insects develop a certain kind of resistance and gradually the pesticides thus sprayed seem to be ineffective on the insects.

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 which will help identify new issues. This is another best practice to follow when testing software.


As explained earlier in the article, the STLC is a testing process that 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 software development process (which includes the testing of the product).

The SDLC aims to produce a high-quality software product which meets the expectations of the client.

The phases defined in the SDLC are:

  1. Requirements Gathering
  2. Design the software
  3. Build the software
  4. Test
  5. Deployment
  6. Maintenance

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 though which are produced 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 through its entire life.

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 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.

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.

Learn more about our QA and testing process here.

Industry Accreditations