The Software Development Life Cycle (SDLC) is the structured process that takes a software project from a vague idea to a running, maintained application. Understanding it is the difference between being a tester who reacts to what arrives on the board and a QA engineer who shapes what gets built from the very beginning.
Learning Objectives
By the end of this lesson you will be able to:
- Name and describe all six SDLC phases
- Explain the cost-of-defects model and its implications for testing strategy
- Identify QA's natural touchpoints in each phase
The Six Phases
Phase 1 — Requirements Analysis
What happens: Business stakeholders, PMs, BAs, and POs identify and document what the software must do. User stories are written, business rules are defined, and constraints are identified (performance, security, legal).
The output: A requirements document, user stories, or a product backlog — depending on the methodology.
QA's role: Review requirements for testability. Can you write a test case for each requirement? If a requirement says "the system shall be fast," it's untestable. A QA engineer asks: "Fast how? Under 200ms? Under 2 seconds under what load?" This is QA at its most valuable.
Phase 2 — Design
What happens: Architects and senior developers plan how the requirements will be implemented. This includes system architecture, database schema, API contracts, security design, and UI wireframes.
The output: Architecture documents, data flow diagrams, API specifications, wireframes.
QA's role: Review designs for testability and edge cases. An API that doesn't define error codes is going to be hard to test. A UI flow with no error states is going to surprise users. Raising these issues in design costs nothing. Raising them in testing costs a rework cycle.
Phase 3 — Development (Implementation)
What happens: Developers write code. Unit tests are written alongside the code. Code reviews happen. The feature is built incrementally.
The output: Working code, merged to a feature branch or main.
QA's role: Monitor progress, refine test cases, and be available to answer questions about expected behaviour. Some teams practice pairing — a developer and a QA engineer work together to clarify behaviour before it's coded. This is ideal.
Phase 4 — Testing
What happens: QA engineers test the built feature against the requirements and Acceptance Criteria. This includes:
- Functional testing — does it do what it's supposed to?
- Regression testing — did this change break anything else?
- Edge case testing — what happens at the boundaries?
- Non-functional testing — performance, security, accessibility
The output: Test reports, bug tickets, a sign-off (or a blocked ticket with open bugs).
QA's role: This is the phase most people think of when they think of QA. But notice it's Phase 4 of 6 — not the only one that matters.
Phase 5 — Deployment (Release)
What happens: The tested, approved software is deployed to production. DevOps engineers manage the deployment pipeline. Go/No-Go decisions are made. Release notes are published.
The output: A live feature in production.
QA's role: Participate in the go/no-go call. Run a post-deployment smoke test to verify the feature works in the production environment (configuration differences can introduce new bugs). Monitor error rates immediately after deployment.
Phase 6 — Maintenance and Support
What happens: The software runs in production. Users find edge cases no test anticipated. Bugs are reported, triaged, and fixed. New requirements emerge from real-world usage.
The output: Bug fixes, patches, and the seeds of the next development cycle.
QA's role: Verify hotfixes before they're deployed. Analyse patterns in production bugs to improve future test coverage. A bug found in production is expensive — but it's also a lesson about what your test suite missed.
The Cost of Defects
This is the most important concept in this entire module.
| Phase where defect is found | Relative cost to fix |
|---|---|
| Requirements Analysis | ~$1 |
| Design | ~$10 |
| Development | ~$100 |
| Testing | ~$1,000 |
| Production | ~$10,000 – $100,000+ |
These numbers are illustrative, but the exponential growth is real and well-documented. A bug found in requirements is a conversation. A bug found in production is an incident.
Why does it cost more later?
- In requirements: you change a sentence in a document
- In design: you update an architecture diagram
- In development: a developer rewrites logic that's already been coded
- In testing: the developer must stop their current work, context-switch, fix the issue, rebuild, and redeploy for retesting
- In production: all of the above, plus user impact, support tickets, potential data corruption, and reputational damage
Career insight: Every minute you spend in Phase 1 reviewing requirements critically is worth 100 minutes in Phase 4 catching bugs. This is why senior QA engineers sit in product planning meetings — not because they love meetings.
The SDLC Is a Cycle, Not a Line
Notice the name: LifeCycle. After Maintenance comes new Requirements — because users always want more, and bugs always surface. The process starts over. Great QA engineers understand this: you're not just here to approve this release. You're building the quality foundations for the next one.
Summary
| Phase | Key output | QA's focus |
|---|---|---|
| Requirements Analysis | Requirements, user stories | Testability review |
| Design | Architecture, wireframes | Edge cases, error states |
| Development | Working code | Test case preparation |
| Testing | Bug reports, sign-off | Full functional + regression testing |
| Deployment | Live feature | Smoke test, go/no-go |
| Maintenance | Bug fixes, patches | Hotfix verification, coverage improvement |
Next lesson: two fundamentally different approaches to organising the SDLC — Waterfall and Agile.