How Traditional Waterfall Lifecycle Models Inhibit Testing


Chapter 2, :"Overview of the Rational Unified Process," identified the four phases of the Waterfall lifecycle: Requirements Elicitation and Analysis, Design, Implementation, and Integration and Test (see Figure 11-1). Each phase has specific activities and skills that are conducted and applied. Although test planning and documentation are typically performed in the earlier phases, the main goal of proving adherence to requirements does not begin until the fourth and last phaseIntegration and Test. Although the Waterfall lifecycle process is conceptually clear, in practice this approach can cause problems with the testing process. The main disadvantages of testing in the Waterfall lifecycle are as follows:

  • As illustrated in Figure 11-1, less than one-half of the project's time is available for testing. No testing can be done during the Requirements Elicitation and Analysis and Design phases, because no development is performed during these phases. Some unit testing can be done during the Implementation phase as coding progresses. However, no system testing, load testing, or stress testing is possible, because no complete, executable release is available for testing. This means that some of the most meaningful tests that are conducted must be completed entirely within the last, final phase of the lifecycle.

  • Because testing occurs at the very end, in one intense "burst," testing personnel have no opportunity to become more proficient with the tools or to easily apply lessons learned to the testing process. They must get all the testing done in one short amount of time.

  • The usefulness of some automated testing tools can be reduced depending on how the code is implemented. If the developers use a technique or method to implement the code (particularly the user interface) that is incompatible with the testing tools, this may not be discovered until testing begins in the Integration and Test phase. Because the majority of the code is already implemented, going back and changing the code's design to make it more compatible with the test tools may be impractical. Changing the test tool at this point means that the investment in the first tool, in terms of both training and the cost of the tool itself, is lost.

  • Many system-level testing tools produce their greatest Return on Investment (ROI) when tests are run in regression fashion, which is difficult to do in a Waterfall approach.

  • The testing occurs during the project's most hectic phase. As discussed in Chapter 2, the discovery of risks in the Waterfall lifecycle model tends to be deferred to the later phases, especially the Integration and Test phase. This is because the final phase is the first time a complete, executable release is created. As a result, testing begins at the same time significant risks are discovered and begin affecting the project. If the risks encountered are serious, the project's focus changes. Instead of getting the system ready to be placed into production, efforts are diverted to solving the problems that crop up during system integration. In fact, it is not unheard of for testing to cease entirely. This is the most stressful time on the project. Team members may even come to view testing as an impediment to project completion. Usually, some testing is done to be able to claim that testing was performed, but the testing is spotty and incomplete at best.

  • If the risks discovered during Integration and Test are severe, defects uncovered by testing efforts receive little attention from the developers. It may not be possible to correct all the bugs discovered before release to the users. At that point, the only choices are to delay the project's release or release it before thorough testing is completed. Unfortunately, this situation reflects poorly on the testers, even though they are not at fault. This is an example of a process problem.

  • Waterfall-based lifecycles do not provide enough flexibility for early deployments of the product being built to have received significant attention through testing. Early releases are, therefore, likely to contain many defects, even if the project is running on schedule overall.

Figure 11-1. Testing in the Waterfall lifecycle model


As a result of these disadvantages, testing on projects using Waterfall lifecycle models often falls short. When a project runs into schedule difficulties, testing is often the first activity to be compromised, partly because of its position in the lifecycle. This is a process problem, not necessarily a weakness of the project personnel, who often work significant overtime to get the project completed on time. When project managers must choose between testing completely and thoroughly versus missing a contractually required completion date, the decision is easy. It's certainly not a good situation, because the failure to get the testing done reflects poorly on the project team. The result may be a project that is delivered on time (or perhaps it is still late despite reducing or eliminating testing) but that performs so poorly it is considered unusable. By the time this discovery is made, the project funding has been consumed. The users of the software then must decide whether they can salvage the project or need to start over.




Project Management with the IBM Rational Unified Process(c) Lessons from the Trenches
Project Management with the IBM Rational Unified Process: Lessons From The Trenches
ISBN: 0321336399
EAN: 2147483647
Year: 2007
Pages: 166

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net