What is the Waterfall Model in Software Testing?
Once upon a time, software development consisted of a programmer writing code to solve a problem or automate a procedure. Nowadays, systems are so big and complex that teams of architects, analysts, programmers, testers and users must work together to create the millions of lines of custom-written code that drive our enterprises.
The oldest of these, and the best known, is the waterfall model: a sequence of stages in which the output of each stage becomes the input for the next. These stages can be characterized and divided up in different ways, including the following:
- Requirement Specification
- Construction (AKA Implementation or Coding)
- Testing (AKA Validation)
The waterfall model is well understood, but it’s not as useful as it once was. The problem is that the waterfall model assumes that the only role for users is in specifying requirements, and that all requirements can be specified in advance. Unfortunately, requirements grow and change throughout the process and beyond, calling for considerable feedback and iterative consultation. Thus many other development models have been developed.
Advantages of waterfall model
- Each phase has specific deliverables and a review process.
- Phases are processed and completed one at a time.
- Works well for smaller projects where requirements are very well understood.
- It reinforces the notions of “define before design” and “design before code”.
Disadvantages of waterfall model
- Adjusting scope during the life cycle can kill a project
- No working software is produced until late during the life cycle.
- High amounts of risk and uncertainty.
- Poor model for complex and object-oriented projects.
- Poor model for long and ongoing projects.
- Poor model where requirements are at a moderate to high risk of changing.
When to use waterfall model
- Such model is highly used where requirements are clear and there will be no changes in the development time. We can find such scenarios in defense projects, where requirements will be clear since before they write requirements they will analyses well.
- We can also name this kind of life cycle model for migration projects, where requirements will be same only platform or languages may vary / change.
- Also can use for projects where sponsor themselves will do testing activities, since till the completion of the coding we will not deliver the project.