When we talk about software development, it is common for the word “testing” to evoke the image of an isolated stage placed at the end of the process — something that happens only after the code has already been written. Although this view still exists in many organizations, it is becoming increasingly disconnected from the reality of mature quality engineering teams.
The STLC (Software Testing Life Cycle) is the structured set of phases that organizes and guides all testing activities throughout development. More than just a sequence of stages, the STLC represents a shift in mindset: quality is not verified at the end, but built in from the beginning.
SDLC and STLC: Two Cycles, One Goal
To understand the STLC, it is helpful to place it within a broader context: the SDLC (Software Development Life Cycle).
The SDLC organizes the software creation process into phases such as:
- Planning
- Requirements Analysis
- Design
- Development (Coding)
- Testing
- Deployment
- Maintenance
In this traditional model, testing appears as a specific phase — a stage between development and deployment. The problem with this approach is that defects found late are significantly more expensive and difficult to fix.
The STLC addresses this issue by structuring testing activities in parallel with and integrated into the SDLC. While the SDLC defines what will be built and how, the STLC defines how quality will be ensured at every stage of that process.
The Relationship Between Development and Testing
This integration is not just a best practice: it is a formalized principle. The ISTQB Foundation Level Syllabus (section 2.1) explicitly states that for every development activity there is a corresponding testing activity, ensuring that all stages of development are subject to quality control. In addition, the syllabus establishes that test analysis and test design for a given level should begin during the corresponding development phase — not after it.
In practice, this means that QA does not wait for the code to be finished before starting work. While requirements are being defined, tests are already being planned. While the system is being designed, test cases are being created. While code is being written, the test environment is being prepared. The table below illustrates this relationship in the context of the classic sequential model:
| SDLC Phase | Corresponding Testing Activity |
|---|---|
| Requirements Analysis | Analysis of testable requirements; identification of test conditions |
| Design | Test planning; strategy definition |
| Development (Coding) | Test case design; test environment setup |
| Testing | Test execution; defect reporting |
| Deployment | Test cycle closure; production sanity testing |
It is worth noting that ISTQB explicitly recognizes that this mapping varies depending on the lifecycle model adopted. In iterative and agile models, phases overlap and are compressed into short cycles — but the principle of correspondence remains: no development delivery should occur without an associated quality activity.
The Phases of the STLC
Contrary to what some materials may suggest, there is no formal or standardized definition of the STLC — no organization such as ISO, IEEE, or ISTQB establishes an official model with fixed and mandatory phases. What is found in technical literature and industry guides is a convergence around six phases, widely adopted by quality teams around the world, but varying in terminology, number of stages, and scope according to the context, methodology, and maturity of each organization.
In this article, I adopt a seven-phase model (6 + 1) as a reference — not because it is “the correct model,” but because it represents a coherent, practical, and sufficiently comprehensive structure for educational and professional purposes. The seventh phase — post-release monitoring — is a deliberate addition to the more common model found in the literature, motivated by the reality of teams operating with continuous delivery that need to extend quality coverage beyond deployment.
Each phase is described with its typical activities and exit criteria, which should be adapted to the reality of each team.
1. Requirements Analysis
Understanding requirements and identifying testable conditions
The first phase of the STLC begins where many still believe testing has no place: planning and requirements analysis. This is where the quality professional (QA) makes one of the most valuable contributions of the entire cycle.
By participating in the initial meetings of an initiative or project — the so-called upstream flow — QA has the opportunity to:
- Identify what can and should be tested, mapping testable conditions directly from the requirements;
- Contribute practical experience by anticipating situations that have historically resulted in failures, highlighting ambiguities in the requirements, and promoting discussions that improve specification quality before a single line of code is written.
This early QA involvement is what supports the concept of shift-left testing — the idea of moving quality activities to the left on the project timeline, making defect detection earlier, cheaper, and more effective.
Exit criteria for this phase: documented list of testable requirements; questions and inconsistencies identified and sent for resolution.
2. Test Planning
Defining the overall testing strategy
With requirements analyzed, the second phase structures the strategy that will guide all remaining activities. The main artifact produced here is the Test Plan — a document that formalizes the key decisions about how testing will be conducted.
A well-designed test plan includes, among other aspects:
- Scope: what will be tested and what is out of scope;
- Strategies: what types of testing will be applied (functional, regression, automated, manual, performance, among others);
- Responsibilities: who will execute the tests, including possible participation from other teams;
- Environments: where tests will be executed (UAT, staging, sandbox);
- Schedule: when testing starts and when it must be completed.
A test plan does not need to be a long, bureaucratic document. In agile contexts, it can be lightweight, continuously updated, and integrated into team management tools — such as a descriptive field in a test suite within an ALM (Application Lifecycle Management) platform.
Exit criteria for this phase: test plan approved by stakeholders; environments defined; schedule agreed.
3. Test Case Design
Developing test cases and scenarios to cover requirements
The third phase transforms requirements into concrete test cases — the scripts that will guide system behavior verification.
A test case describes, in a structured way, the input conditions, actions to be performed, and expected results for each verification scenario. Its creation requires both technical knowledge and business understanding: a good test case covers the expected scenario (happy path), variations, and exception scenarios.
Test cases may be written in different formats:
- Natural language (step-by-step): more accessible for multidisciplinary teams, describing each user action and expected result sequentially;
- Gherkin language (BDD): behavior-oriented, using the Given / When / Then structure so business and technology share the same vocabulary.
In addition to creation, this phase also includes test case review — a step often neglected, but essential to ensure proper coverage and eliminate redundancies.
Exit criteria for this phase: test cases documented, reviewed, and organized into suites; requirements coverage verified.
4. Test Environment Setup
Preparing the infrastructure where tests will run
Before any test is executed, it is necessary to ensure that the environment where it will occur is properly prepared. This phase focuses on the installation, configuration, and validation of test environments.
A test environment should ideally reflect production — in terms of operating system, software versions, data volumes, and network settings. The gap between test and production environments is one of the main reasons defects escape testing and are found only in production.
Typical activities in this phase include:
- Provisioning or updating the environment (machines, containers, servers, databases);
- Configuring suitable and representative test data;
- Validating that the environment is functional and accessible for the testing team;
- Setting up testing tools (frameworks, automation tools, evidence collectors).
In organizations with mature DevOps practices, much of this is automated — with environments created and destroyed on demand as part of CI/CD pipelines.
Exit criteria for this phase: validated and documented test environment; tools configured and operational.
5. Test Execution
Running test cases and recording results
This is the phase where planned test cases are actually executed. For each test case, QA follows the defined script, records the obtained result, and compares it with the expected result.
When behavior differs from what is expected, there is a failure — which must be investigated to determine whether it is a software defect (bug), an environment issue, a specification inconsistency, or an inadequate test case.
Identified defects must be documented individually and in detail, including:
- Clear description of observed behavior vs. expected behavior;
- Steps to reproduce;
- Evidence (screenshots, logs, videos);
- Severity and priority;
- System version where the defect was found.
This documentation is essential so developers can investigate and fix problems efficiently, and so QA can verify the fix afterward (retesting).
At the same time, execution results feed reports and dashboards that provide real-time visibility into progress and delivery quality.
Exit criteria for this phase: all planned test cases executed; defects documented and assigned; execution report available.
6. Test Cycle Closure
Consolidating results and analyzing activities
The sixth phase formalizes the closure of the testing cycle in the controlled environment. More than a final report, closure is an opportunity for organizational learning.
Activities in this phase include:
- Results analysis: how many cases were executed, passed, failed, or blocked; what is the status of identified defects;
- Coverage evaluation: were requirements adequately covered by testing?
- Lessons learned: what worked well in the process? What can be improved next cycle?
- Artifact archiving: test cases, reports, and evidence organized for future reference.
In many organizations, this phase also includes presenting results to stakeholders — especially when testing revealed relevant risks or coverage was below plan.
Exit criteria for this phase: final test report published; lessons learned recorded; quality metrics consolidated.
7. Beyond the STLC: Post-Release Monitoring
Verifying the release in production and continuous monitoring
In teams with DevOps and continuous delivery practices, QA responsibility does not end with deployment. After production release, this phase ensures that the delivery works as expected in the real environment — which is, by definition, the most unpredictable of all.
Typical activities in this phase include:
- Executing non-invasive tests in production — so-called smoke tests or sanity tests — to confirm critical functionalities are operating correctly after release;
- Monitoring automated regression tests to ensure the new release did not introduce breaks in previously validated functionality;
- Monitoring production quality indicators (error rates, exception logs, performance alerts) as a complementary signal to test coverage.
Including this phase in the model reflects a broader quality vision: production is the final judge, and QA should have visibility into what happens there after each release.
Exit criteria for this phase: smoke tests executed and passed; absence of critical regressions confirmed; production stability evidence recorded.
Quality Control, Assurance, and Management in the STLC
The STLC operates across three complementary quality dimensions:
- Quality Control (QC): verification activities — finding defects through test execution;
- Quality Assurance (QA): prevention activities — ensuring development and testing processes are adequate to produce quality software;
- Quality Management: planning, monitoring, and continuous improvement of quality processes.
QA professionals who operate across all STLC phases naturally move among these three dimensions — and this broad performance is what differentiates a mature quality team from one that simply “tests at the end.”
Conclusion
The STLC represents the systematic organization of testing activities throughout the entire development lifecycle. By structuring quality into phases with defined inputs, activities, and exit criteria — and by integrating QA from requirements analysis onward — the STLC transforms quality from a one-time event into a continuous process.
Understanding and applying the STLC is a fundamental step for teams seeking not only to find defects, but to prevent them — delivering better software with greater predictability and less rework.
