The Software Testing Lifecycle (STLC) is the QA-specific cousin of the SDLC. Where the SDLC describes how software gets built, the STLC describes how testing gets done within it. The phases are deliberately distinct from coding phases — they describe testing activities, not engineering activities — and they happen continuously, not at the end.
The six phases of STLC
1. Requirements analysis. Read the requirements through testing eyes. What is testable, what is ambiguous, what is high-risk? The artefact you produce is a list of clarifying questions and a rough sense of where to spend your effort.
2. Test planning. Decide the strategy: what types of testing, with what tools, on what environments, to what coverage target. The artefact is a test plan — short or long, formal or informal, depending on the team.
3. Test design. Write the actual test cases. For each requirement, define the inputs, the steps, and the expected outcome. Apply techniques like equivalence partitioning and boundary value analysis to decide which inputs to use.
4. Environment setup. Make sure the test environment is ready — staging deployed, test data seeded, test fixtures loaded, monitoring connected. This phase is where releases get delayed; treat it as first-class work.
5. Test execution. Run the tests, both automated and manual. Log defects as they are found. Re-run tests after fixes. This is the most visible phase but rarely the longest.
6. Test closure. Wrap up: write a summary report, file follow-up tickets for known issues, capture lessons learned, close the cycle. This is the phase teams skip most often, and it is the one that makes the next cycle smarter.
How STLC fits inside SDLC
Imagine the SDLC as the trunk of a tree. STLC is a branch that grows out of every part of the trunk:
- During the SDLC's requirements phase, the STLC is in requirements analysis.
- During the SDLC's design phase, the STLC is in planning and design.
- During the SDLC's development phase, the STLC is in environment setup and execution.
- During the SDLC's deployment phase, the STLC is in execution and closure.
In a strict waterfall project the phases happen once, in order. In agile or continuous delivery, they happen many times — sometimes within a single sprint. A two-week sprint might run the entire STLC for one feature while another feature is in a different phase.
Inputs and outputs of each phase
| Phase | Key input | Key output |
|---|---|---|
| Analysis | Requirements / user stories | List of risks and questions |
| Planning | Risks, scope, constraints | Test plan |
| Design | Requirements + plan | Test cases, test data |
| Setup | Plan + cases | Working test environment |
| Execution | Cases + environment | Test results, bug reports |
| Closure | Results + reports | Summary, follow-ups, retrospectives |
Why a deliberate process matters
A common failure mode is collapsing the STLC into a single chaotic phase called "QA." Tickets pile up, testers scramble, the team misses obvious risks, and the release ships late. Following STLC steps deliberately — even informally on a sticky note — forces a rhythm: think first, plan, design, set up, execute, then reflect.
What you should walk away with
STLC is the rhythm of QA work. Each phase has a clear purpose, a clear input, and a clear output. In agile teams these phases happen quickly and often overlap — but skipping any of them entirely is a smell. Up next: how the STLC plays out differently in agile vs waterfall projects.