What is the SDLC?
The Software Development Life Cycle (SDLC) is a framework that defines the process for planning, creating, testing, and deploying software. Different SDLC models describe different approaches to organizing these activities.
Understanding SDLC models is essential for testers because your testing approach is shaped by the development model your team follows. When you test in a Waterfall project, your activities, timing, and deliverables are fundamentally different from testing in an Agile project.
In this lesson, we explore the oldest and most structured SDLC model: Waterfall.
The Waterfall Model
The Waterfall model was first described by Winston Royce in 1970 (though ironically, Royce presented it as an example of a flawed approach). Despite that, it became the dominant software development methodology for decades.
Waterfall is a sequential, linear model. Each phase must be completed fully before the next phase begins. Like water flowing over rocks in a waterfall, progress flows in one direction — downward.
What to build] --> D[Design
How to build it] D --> I[Implementation
Building it] I --> T[Testing
Verifying it works] T --> Dep[Deployment
Releasing it] Dep --> M[Maintenance
Supporting it] style R fill:#3b82f6,color:#fff style D fill:#6366f1,color:#fff style I fill:#8b5cf6,color:#fff style T fill:#a855f7,color:#fff style Dep fill:#d946ef,color:#fff style M fill:#ec4899,color:#fff
The Six Phases
1. Requirements
The project begins with gathering and documenting all requirements. Business analysts, product managers, and stakeholders define what the system must do. The output is a detailed requirements specification document (SRS — Software Requirements Specification).
QA involvement: Testers review requirements for testability, completeness, consistency, and ambiguity. They begin writing high-level test plans.
2. Design
Architects and senior developers design the system based on the requirements. This includes system architecture, database schemas, API contracts, UI wireframes, and technology choices. The output is a design specification document (SDD — Software Design Description).
QA involvement: Testers review design documents and begin designing test cases. Test architects plan the test environment and infrastructure.
3. Implementation (Coding)
Developers write the code according to the design specification. This is typically the longest phase. Developers may write unit tests during this phase, but formal testing is reserved for the next phase.
QA involvement: Limited during coding. Testers finalize test cases, prepare test data, and set up test environments. Some teams have testers review code for testability.
4. Testing
After implementation is complete, the system is handed to the testing team. Testers execute test cases, perform integration testing, system testing, and report defects. Developers fix bugs and testers re-verify the fixes.
QA involvement: This is the QA team’s primary active phase. All planned test cases are executed, defects are logged and tracked, and a test summary report is produced.
5. Deployment
Once testing is complete and the product meets acceptance criteria, it is deployed to production. This may include user acceptance testing (UAT) with actual users or customers.
QA involvement: Smoke testing in the production environment, monitoring for deployment-related issues.
6. Maintenance
After deployment, the team provides ongoing support — fixing bugs reported by users, releasing patches, and occasionally adding minor features. Each change may trigger a mini-waterfall of its own.
QA involvement: Regression testing for each maintenance release, verifying bug fixes.
Advantages of Waterfall
Clear structure and milestones. Each phase has defined deliverables and exit criteria. Management can easily track progress: “We are in the Design phase, 70% complete.”
Comprehensive documentation. Waterfall produces detailed documentation at every stage. This is valuable for compliance, onboarding new team members, and long-term maintenance.
Predictable timelines and budgets. Because all requirements are defined upfront, it is easier to estimate costs and timelines. Contracts can be signed with fixed scope and price.
Works well for regulated industries. Medical devices (FDA), aviation (DO-178C), defense, and government contracts often require the traceability and documentation that Waterfall provides naturally.
Simple to understand and manage. The linear nature makes Waterfall intuitive. Everyone knows what phase the project is in and what comes next.
Disadvantages of Waterfall
Late testing. The biggest problem for QA: testing happens at the end. If fundamental design decisions are wrong, they are discovered late when fixing them is extremely expensive.
No working software until late. Stakeholders do not see a working product until the Testing or Deployment phase. If it does not meet their expectations, major rework is needed.
Poor handling of change. Waterfall assumes requirements are complete and stable from the start. In reality, business needs change, competitors release new features, and users provide feedback that invalidates original assumptions.
Big-bang integration. All components are integrated at once during the Testing phase, making it difficult to isolate the source of problems.
High risk. If a critical error in requirements is not caught until testing, the entire project may need significant rework, potentially blowing the budget and timeline.
How Testing Fits in Waterfall
In Waterfall, the QA role evolves across phases:
| Phase | QA Activity | Deliverable |
|---|---|---|
| Requirements | Review requirements, write test plan | Test Plan |
| Design | Review design, design test cases | Test Cases |
| Implementation | Prepare test environment, finalize test data | Test Environment, Test Data |
| Testing | Execute tests, report defects, retest fixes | Test Execution Report, Defect Reports |
| Deployment | Smoke testing, UAT support | Deployment Verification Report |
| Maintenance | Regression testing | Regression Test Report |
The Testing Phase Crunch
A well-known problem in Waterfall: the testing phase gets compressed. Development runs over schedule (it almost always does), but the deployment deadline remains fixed. The result: the testing phase — originally planned for 4 weeks — gets squeezed to 2 weeks.
This pressure leads to:
- Reduced test coverage
- Prioritizing only happy-path testing
- Skipping non-functional testing (performance, security)
- Testers working overtime
- Bugs being deferred rather than fixed
This pattern is one of the primary motivations for moving to iterative and Agile models.
When Waterfall Works Well
Despite its limitations, Waterfall is still appropriate in certain contexts:
- Regulatory compliance projects where documentation and traceability are mandatory
- Hardware-software integration where hardware components have long lead times
- Well-understood domains where requirements are stable and well-documented (e.g., reimplementing an existing system in a new technology)
- Fixed-price contracts where scope must be locked before development begins
- Small projects with clear, simple requirements that are unlikely to change
Exercise: Identify Waterfall Problems
Read the following case study and identify at least 5 problems caused by using the Waterfall model:
Case Study: Hospital Patient Management System
A hospital contracted a software company to build a patient management system. The project used Waterfall:
- Month 1-2: Requirements gathered from hospital administrators (doctors and nurses were not consulted)
- Month 3-4: System designed with a desktop-first interface
- Month 5-8: Development completed
- Month 9-10: Testing began — 47 critical bugs found, including data entry screens that required 25+ clicks for common tasks
- Month 10: Hospital administrators saw the system for the first time and requested 30+ changes to workflows
- Month 11: Deadline hit. System deployed with known defects. Nurses refused to use it, citing that it was slower than paper records.
Hint
Consider: stakeholder involvement, requirements quality, late feedback, testing timing, and user acceptance.Solution
Incomplete stakeholder involvement: Only administrators were consulted during requirements. Doctors and nurses — the primary users — were excluded. This virtually guaranteed the system would not meet user needs (Principle 7: Absence-of-errors fallacy).
No early validation: No prototypes or wireframes were shown to actual users until month 10. Ten months of work was based on assumptions about user needs.
Late testing discovered fundamental problems: 47 critical bugs and 25+ clicks for common tasks suggest design-level issues, not just coding bugs. These were found too late to fix economically.
Requirements change was inevitable but unplanned: The 30+ requested workflow changes at month 10 were predictable — requirements gathered without user input will not match user needs.
Testing phase compression: The original 2-month testing phase was compressed as the deadline approached, resulting in known defects being shipped.
No iterative feedback: If the team had shown a working prototype after month 4, the workflow issues would have been discovered 6 months earlier.
Desktop-first design assumption: In 2024+, hospital staff move between stations. A desktop-first approach was likely wrong, but this assumption was baked in at the design phase and never questioned.
An iterative approach would have caught most of these issues within the first 2-3 months, at a fraction of the eventual cost.
Pro Tips
Tip 1: Even in Waterfall, push for early testing activities. You cannot control the SDLC model, but you can advocate for requirements reviews, design reviews, and early prototyping. These shift-left activities prevent defects even within a Waterfall framework.
Tip 2: Document everything — it is Waterfall’s strength. In Waterfall, comprehensive documentation is not overhead — it is a feature. Write thorough test plans, detailed test cases, and complete defect reports. This documentation serves as evidence of testing rigor for audits and compliance.
Tip 3: Negotiate testing time in the project plan. If you are on a Waterfall project, fight for adequate testing time at the planning stage. Once the schedule is locked, the testing phase will always be the one that gets squeezed.
Key Takeaways
- Waterfall is a sequential SDLC model where each phase must complete before the next begins
- Its six phases are: Requirements, Design, Implementation, Testing, Deployment, Maintenance
- Testing is concentrated in a dedicated phase after implementation — this is Waterfall’s biggest weakness for QA
- Waterfall excels in regulated industries, fixed-price contracts, and projects with stable requirements
- The testing phase is routinely compressed when development overruns, reducing test coverage
- Despite its limitations, Waterfall principles (documentation, traceability, phase gates) remain valuable even in Agile environments