Agile vs Waterfall
Both are ways to organize software development (SDLC models). Waterfall moves through fixed phases in order — requirements, design, build, test, release — and delivers once at the end. Agile delivers working software in short cycles (sprints), testing and adjusting continuously. For testers, the biggest difference is when testing happens: at the end in Waterfall, all the time in Agile.
Comparison at a Glance
| Aspect | Waterfall | Agile |
|---|---|---|
| Approach | Sequential phases | Iterative and incremental |
| Planning | Detailed plan up front | High-level roadmap, detailed per sprint |
| Requirements | Fixed and fully documented at the start | Evolving user stories in a prioritized backlog |
| Testing starts | After development is complete | In every sprint, from refinement onwards |
| Working software | At the end | At the end of every sprint |
| Changing requirements | Expensive — formal change requests | Expected — reprioritise the backlog |
| Customer feedback | Late | Every sprint (sprint review) |
| Documentation | Heavy and formal | Lighter, "just enough" |
| Team structure | Specialist teams handing work over | Cross-functional team working together |
| Risk | Problems surface late | Problems surface early, in small increments |
| Fits best | Stable, well-understood requirements; regulated or fixed-scope work | Changing requirements and fast feedback — most product development |
The Waterfall Model
Requirements → Design → Development → Testing → Deployment → Maintenance
Each phase finishes, is signed off, and hands over to the next. Requirements are frozen early and changes go through formal change control.
Testing in Waterfall
- Testers write the test plan and test cases from the complete requirements document, often while development is under way.
- Test execution starts only when the build arrives, in a dedicated testing phase.
- Defects found now can be expensive: the design may need to change, and the release date is close.
- Regression is usually one large cycle before release.
The V-Model
A Waterfall variant that pairs each development phase with a testing level — requirements with acceptance testing, system design with system testing, architecture with integration testing, module design with unit testing. Test planning starts early, but execution still happens after development. It's common in regulated industries such as medical devices, automotive and aerospace. More: SDLC & STLC Models.
The Agile Model
Agile is a set of values and principles (the Agile Manifesto) favoring working software, collaboration and responding to change. Most teams practice it through Scrum:
- Sprints of 1–4 weeks, each producing a potentially shippable increment.
- Roles: Product Owner (priorities), Scrum Master (process), Developers (including testers).
- Events: sprint planning, daily scrum, sprint review, retrospective — plus backlog refinement.
- Artifacts: product backlog, sprint backlog, increment; a shared Definition of Done that includes testing.
Kanban is the other common approach: continuous flow with work-in-progress limits instead of fixed sprints. More: Agile & Scrum for Testers.
One Feature, Built Both Ways
Feature: online payment in a shopping app.
Waterfall
- Months 1–2: full requirements for payments, refunds, invoices and reports are written and signed off.
- Months 3–5: design and development of the whole payment module.
- Month 6: testers receive the complete module — and find that the refund rules don't match how finance actually works.
- The fix touches the design, and the release slips.
Agile
- Sprint 1: card payment only. Testers help write acceptance criteria in refinement, test the story as soon as it's built, and automate the happy path.
- Sprint 2: refunds. At the sprint review, finance sees the refund screen and corrects a rule — two weeks after it was built, not five months.
- Sprint 3: invoices. Automated regression confirms payments and refunds still work.
The difference isn't that Agile has no problems — it's that problems appear while they're still small and cheap to fix.
What It Means for Testers
| Area | Waterfall | Agile |
|---|---|---|
| Involvement | Mostly after development | From refinement and sprint planning onwards |
| Test basis | Complete requirement specification | User stories and acceptance criteria |
| Documentation | Detailed test plans and cases | Lighter test cases, checklists, exploratory charters |
| Feedback loop | Long | Short and continuous |
| Collaboration | Formal hand-offs | Daily, with developers and the product owner |
| Regression | One large cycle before release | Every sprint — ideally automated in CI |
| Key skills | Thorough test design and documentation | Communication, fast test design, exploration, automation |
Why automation matters more in Agile
Every sprint adds features and changes existing ones, so regression has to run every sprint — and often on every commit. Doing that by hand quickly becomes impossible, which is why Agile teams invest in automated smoke, API and regression suites running in CI. See Manual vs Automation Testing.
Hybrid Approaches in Real Companies
Many organizations mix both: Agile sprints for development inside a Waterfall-style release process with fixed milestones, formal UAT and sign-off (sometimes called "Water-Scrum-Fall"). Testers in these teams test continuously during sprints but still support a final hardening or UAT phase. Being able to describe how your own project really worked is more convincing in interviews than textbook definitions.
When to Use Each
Waterfall fits when
- Requirements are stable, well understood and unlikely to change.
- Regulations require formal documentation, phase sign-offs and traceability.
- The contract fixes scope, price and deadline up front.
- The work is hard to deliver in small pieces (some hardware or infrastructure projects).
Agile fits when
- Requirements will change or aren't fully known yet.
- Early, frequent user feedback is valuable.
- The product can be released in small increments.
- A cross-functional team can work closely with the business.
Practice testing decisions in realistic sprint situations in the Manual Testing Simulator.
The Interview Answer
"Waterfall is sequential — requirements, design, development, then testing — so testing happens late and changes are expensive. Agile delivers in short sprints, so testing happens continuously: I join refinement to clarify acceptance criteria, test stories as soon as they're ready, and our regression is automated so it can run every sprint. Waterfall still suits projects with fixed, well-understood requirements or strict regulation; Agile suits most product development where requirements change."
From Real Projects
On Apkope, Canolog and Testsigma I took part in Agile ceremonies — daily stand-ups, sprint planning, sprint reviews and retrospectives. The tester's voice matters in each: raising testing effort in planning, blockers in stand-up, and quality issues in the retrospective. Testing works best when it starts with the requirement, not after development finishes. In Agile, testing starts with the story, not after development is finished.
📚 Official documentation: ISTQB Glossary of testing terms
Frequently Asked Questions
What is the difference between Agile and Waterfall?
Waterfall completes each phase before the next and delivers once at the end; Agile delivers working software in short sprints with continuous testing and feedback.
When does testing begin in each model?
In Waterfall, test execution starts after development is complete (planning can start earlier). In Agile, testing happens throughout every sprint.
Which model is better?
Neither universally. Agile suits changing requirements and fast feedback; Waterfall suits stable, well-defined or heavily regulated projects.
What is the V-Model?
A Waterfall variant that pairs each development phase with a corresponding testing level, so test planning starts early.
Is Scrum the same as Agile?
No — Agile is the set of values and principles; Scrum is one framework for practicing it (Kanban is another).
Why is automation more important in Agile?
Regression must run every sprint and often on every commit — too often to do manually.
Related
- The Complete Manual Testing Tutorial
- Jira Boards, Sprints & Agile
- Top 30 Manual Testing Interview Questions
