SDLC & STLC
The Software Development Life Cycle (SDLC) describes how software is planned, built, released and maintained. The Software Testing Life Cycle (STLC) describes how it is tested. STLC runs inside SDLC, and it starts when requirements exist, not when code is finished.
| Aspect | SDLC | STLC |
|---|---|---|
| Focus | Building the product | Verifying and validating the product |
| Owner | The whole team: product, design, engineering | QA and test engineers, together with developers |
| Starts | With a business need or idea | As soon as requirements exist |
| Output | Working software | Evidence of quality: results, defects, a closure report |
SDLC: the six phases
| Phase | Goal | Key outputs | Quality activities |
|---|---|---|---|
| 1Requirements | Decide what to build and why | User stories, acceptance criteria | Review for ambiguity, testability and missing edge cases |
| 2Design | Decide how to build it | Architecture, data models, API contracts | Design reviews, threat modelling, testable interfaces |
| 3Implementation | Build it | Source code, unit tests | Code review, static analysis, unit tests, TDD |
| 4Testing | Verify and validate it | Test results, defect reports | Integration, system, regression and acceptance testing |
| 5Deployment | Release it to users | Release build, release notes | Smoke tests, canary checks, a tested rollback plan |
| 6Maintenance | Operate and improve it | Patches, enhancements | Monitoring, incident analysis, regression tests for fixes |
Every SDLC model uses these phases. Waterfall runs them once, in order. Agile runs the whole loop every sprint. The V-model pairs each build phase with a test level. DevOps compresses the loop with CI/CD so it can run many times a day.
STLC: the six phases
| Phase | Entry criteria | Activities | Deliverables |
|---|---|---|---|
| 1Requirement analysis | Requirements or stories are available | Identify testable requirements, raise questions, define scope, assess automation | Requirements traceability matrix (RTM), clarified questions |
| 2Test planning | Requirements analysed | Choose strategy, scope, tools, roles, schedule; assess risks; estimate effort | Test plan, effort estimate |
| 3Test case development | Test plan approved | Write test cases and automation scripts, prepare test data, peer review | Reviewed test cases, test data, scripts |
| 4Environment setup | Architecture known; often parallel to phase 3 | Provision environments, seed data and accounts, smoke-test the environment | Ready environment, smoke-test results |
| 5Test execution | Test cases, environment and a testable build are ready | Run tests, log defects, retest fixes, run regression | Execution report, defect reports, updated RTM |
| 6Test cycle closure | Execution done or exit criteria met | Evaluate coverage against exit criteria, collect metrics, hold a retrospective | Test closure report, lessons learned |
How they fit together: the V-model
The V-model makes the link between the two lifecycles explicit. Each build phase on the left produces the basis for a test level on the right. Tests for a level are designed when its partner phase finishes, long before they run.
- During requirements, analyse testability and draft acceptance tests.
- During design, plan system and integration tests against the contracts.
- During implementation, write unit tests with the code, and prepare environments and data.
- During testing, execute, log defects and retest. At release, smoke test and close the cycle.