The Software Development Lifecycle (SDLC) is the structured process every team follows — formally or informally — to take an idea from "we should build this" to "this is running in production." Understanding the SDLC matters for QA because each phase produces artefacts you can test, and each transition introduces risk.
The classic six phases
1. Requirements. Stakeholders decide what to build. Product managers, designers, engineers, and QA hash out user stories, acceptance criteria, and constraints. The output is a written specification — a backlog, a PRD, a design doc, or some combination.
2. Design. Technical leaders translate requirements into architecture. They decide which services own which data, which APIs to build, which third parties to integrate. The output is a design document, system diagrams, and database schemas.
3. Development. Engineers write the code that delivers the design. This is the longest phase in most projects, full of pull requests, code reviews, and incremental merges.
4. Testing. QA validates that the build matches the requirements. In modern teams this is not a separate phase but woven through development — but the activities are still distinct.
5. Deployment. The build is shipped to users. This may be a single big-bang release or a continuous trickle of small changes through a pipeline.
6. Maintenance. The work that follows release: bug fixes, incident response, small enhancements, performance tuning, security patches.
Why QA cares about every phase
It is tempting to think QA only matters at phase 4. Modern thinking — captured by the term shift-left — argues the opposite. The earlier QA gets involved, the cheaper defects are to fix.
- Requirements phase. A QA engineer reviewing a user story can spot ambiguous acceptance criteria before any code is written. "Login should be fast" — what does that mean? 200ms? 2 seconds? Push for a number.
- Design phase. Reviewing the design surfaces testability concerns. Is there a way to set up test data without going through the UI? Are error states well-defined? Is there a way to inject failures for chaos testing?
- Development phase. Pair with developers on tricky logic. Write your test cases as the feature is being built — not after — so you can catch issues while the developer still has the code in their head.
- Deployment phase. Verify smoke tests on staging, run validation in production after the deploy, monitor error rates for 30 minutes after release.
- Maintenance phase. Reproduce customer-reported bugs, write regression tests for them, audit older areas of the codebase that have not been touched in a while.
Common SDLC models
The same six phases can be arranged differently depending on the project's risk profile and the team's culture:
- Waterfall runs the phases sequentially, with formal sign-offs between each. Heavy upfront documentation, slow to change direction. Still common in regulated industries (medical, aerospace, defence) where the cost of a wrong decision is enormous.
- Iterative / Agile runs the phases in short loops — typically one to four weeks — and ships every loop. Embraces change, surfaces problems quickly, but requires discipline about what "done" means.
- DevOps / Continuous Delivery collapses the deployment phase to near-zero by automating the pipeline. Code can be in production within hours of being merged, sometimes within minutes.
- V-model is a waterfall variant that explicitly maps each development phase to a testing phase — requirements ↔ acceptance testing, design ↔ system testing, etc.
What you should walk away with
The SDLC is the macro process — the big-picture flow of how software gets made. The next lesson zooms into the QA-specific micro-process that lives inside it: the Software Testing Lifecycle.