Understanding the Software Testing Life Cycle in Modern QA

Earlier approaches to the Software Testing Life Cycle (STLC) used to be a neat sequence of phases, where releases happened only after every stage was completed.

This will no longer cut it in modern teams. For instance, in my team, requirements evolve during development, and I expect my testers to provide feedback at earlier stages. Despite these changes, the core principles behind STLC remain relevant, and worth learning.

Whether you’re working in a traditional enterprise environment or a modern DevOps setup, knowing the fundamentals of STLC can improve both test planning and execution.

In this guide, we’ll explore what STLC is, its phases, how it differs from SDLC, and how modern teams adapt the testing life cycle within Agile and CI/CD workflows.

What Is Software Testing Life Cycle (STLC)?

STLC is a coordinated, step-by-step process that Quality Assurance teams follow, to make sure that their software product meets business goals and technical requirements before it gets released.

The goal of STLC is to ensure that testing is planned, executed, tracked, and completed systematically. Therefore, each phase has specific objectives, deliverables, entry criteria, and exit criteria.

A typical STLC is an iterative process consisting of six core phases: requirement analysis, test planning, test case development, test environment set up, test execution, and final test closure.

While the order remains similar across projects, modern methodologies often overlap or compress these phases. For instance, our team embeds STLC activities continuously into each sprint rather than running them as a separate testing phase after development.

Software Testing Life Cycle (STLC) Phases Explained

Below is the breakdown of each step of the STLC process, along with entry and exit criteria and common mistakes I’ve seen in each phase. Entry and exit criteria create checkpoints that help teams maintain consistency and prevent important activities from being skipped.

Requirement Analysis

As a first step, the testing team reviews business objectives and technical requirements to define what needs to be tested.

The key steps include:

• Reviewing business and technical requirements
• Identifying test scenarios
• Clarifying ambiguities with relevant stakeholders
• Assessing risks and dependencies
• Assessing the feasibility of automating tests
• Creating a Requirements Traceability Matrix (RTM)

Entry Criteria: User stories are available, and acceptance criteria is defined.

Exit Criteria: The requirements are mapped to the Requirements Traceability Matrix, and are approved.

One mistake I’ve observed is that teams sometimes accept vague requirements without clarifying them. This invariably results in late-stage changes that lead to delays in the release.

Test Planning

This is the main strategy phase where QA leads like me define the scope, objectives, timeline, and resource allocation for the testing process.

Some of the activities include:

• Estimating effort and timelines
• Selecting testing methodologies/tools
• Allocating resources
• Defining entry and exit criteria for each phase

Entry Criteria: When requirement documents are signed off.

Exit Criteria: When the test plan is finalized and timelines have been set.

The output is typically a test plan document that serves as the roadmap for testing activities. A common mistake in this phase is creating an inflexible test plan. Make sure that your test plan is flexible enough to adapt to changing timelines.

Test Case Development

In this phase, testers design test scenarios and test cases on the basis of the test plan document.

Activities include:

• Writing detailed test cases
• Preparing test data
• Establishing expected results
• Designing automation scripts (when needed)
• Reviewing test coverage

Entry Criteria: When the test plan has been approved by relevant stakeholders, and the test data is ready.

Exit Criteria: When test cases and automation scripts have been mapped to requirements and reviewed.

An effective test design should take into account positive and negative scenarios, edge cases, and error handling. I’ve seen production issues arise from overlooked edge cases, so this phase should not be treated trivially.

Test Environment Setup

The required infrastructure and configurations are prepared at this stage, that is, the setting up of the specific hardware, software, and network conditions required to execute the tests.

The tasks at this stage are:

• Environment provisioning
• Application deployment
• Test data preparation
• Tool configuration
• Access management

Entry Criteria: When the test setup plan is defined, and configurations are in place.

Exit Criteria: Environment is signed off as stable for testing.

A common issue I’ve seen at this stage is that the test environment does not mirror the production environment, which can lead to flaky tests.

Test Execution

This is the phase where testers run the pre-written test cases against the developed software.

Key actions include:

• Running manual tests
• Executing automated tests
• Capturing evidence
• Logging defects
• Retesting fixes

Execution should focus not only on finding defects but also on identifying unexpected user behaviors and workflow gaps. One mistake here is skipping smoke tests and sanity checks. Test execution should be a balance between automation testing and risk-based manual testing.

Entry Criteria: After test cases are finalized and the environment is validated.

Exit Criteria: Test cases are executed, defects are resolved, regression testing is complete, and results are documented.

Test Closure

The final phase evaluates testing outcomes and captures lessons learned.

The steps are:

• Reviewing test coverage
• Analyzing defect trends
• Documenting metrics
• Preparing closure reports
• Identifying process improvements

Entry Criteria: When all defects have been resolved, and the final test report has been approved.

Exit Criteria: Closure reports have been reviewed and lessons learned are documented.

This phase is often taken lightly, but I would warn QA teams against that. Comprehensive retrospective reviews help ensure that high QA standards are maintained.

Software Testing Life Cycle (STLC) vs Software Development Life Cycle (SDLC)

SDLC (Software Development Life Cycle) is the end-to-end process of designing, building, and delivering software.

STLC (Software Testing Life Cycle) is a subset of SDLC that is focused on validating software quality before its release into production.

Below is a summary of the key differences between SDLC and STLC:

Software Testing Life Cycle (STLC) Models Explained

Waterfall Model

This is a strictly linear and sequential methodology where each phase must be completed before the next one begins.

This model works best for projects with clearly documented and unchanging requirements, and fixed deadlines.

Agile Model

This is a modern methodology that most modern product companies follow, including mine. This is an iterative and incremental approach where software is developed in sprints. Feedback is frequent, and there is more collaboration between developers and testers.

One issue with this model is that it can lead to scope creep if requirements are not actively monitored and managed.

V-Model

Here, testing activities are planned alongside development phases. Some of the pros of following the V-Model includes early defect detection and stronger traceability.

Many regulated industries (such as finance and healthcare) favor the V-Model because of its structured approach and greater oversight over defects.

Spiral Model

A risk-driven process model that loops through planning, risk analysis, engineering, and evaluation. Testing and risk assessment occur during repeated development cycles.

Benefits include stronger risk management and continuous refinement.

I’ve seen this model favoured in large, complex projects (such as banking projects) where requirements may change significantly.

Software Testing Life Cycle (STLC) in Agile and CI/CD

Because so many modern product teams have moved to Agile ways of working, it is good to understand how to adapt STLC phases accordingly.

The main difference is that testing is continuous, iterative, and integrated into every sprint. In mature CI/CD pipelines, many testing activities happen automatically whenever code changes are committed.

The phases themselves remain the same, but they are compressed and overlap significantly:

• Requirement Analysis: QA teams review user stories, identify risks, and define testable acceptance criteria before development begins.
• Test Planning: Teams create lightweight sprint-level test plans that focus on feature scope, automation opportunities, and regression coverage.
• Test Case Development: Test cases and automation scripts are developed alongside the feature, often using practices such as BDD (Behavior-Driven Development) to align testing with business requirements.
• Test Environment Setup: Modern teams rely on cloud environments, containers, and infrastructure automation.
• Test Execution: Testing occurs throughout the sprint. Automated unit, integration, and regression tests run continuously through CI/CD pipelines, while manual testing focuses on exploratory and user-centric scenarios.
• Test Closure: Instead of waiting until the end of a large release, teams review defect trends and test coverage at the end of each sprint, during retrospectives.

There are two major shifts in Agile teams. One, there is a reduction in waiting time between phases. Secondly, there is more collaboration between developers, testers and product stakeholders throughout the sprint.

Final Thoughts

Over the years, software delivery has become faster, more iterative, and increasingly automated. Yet, every successful QA process I’ve seen still follows the core ideas behind STLC. Activities may overlap, automation may execute tests automatically, and deployments may happen multiple times a day. But teams still analyze requirements, plan testing, create test cases, execute validations, manage defects, and review outcomes.

And that is why understanding STLC remains valuable.

If you’re new to QA, STLC provides a framework for thinking systematically about testing. If you’re already working in Agile or DevOps environments, it helps you recognize how modern testing practices evolved from these foundational principles.