Software Testing in Sequential Lifecycle models (waterfall, v-model)

Sequential lifecycle models involve building the system in a sequence of steps or phases. Common sequential lifecycle models are the Waterfall model and the V model. These models have been around for a long time and are sometimes referred to as the traditional lifecycle models.

In this post, let us look at the nature of issues these models can pose to testing, by first examining some of the characteristics of these models.

• The Software Testing phase in sequential models is slated to occur towards the end of the lifecycle
• These models tend to be schedule and budget driven with delivery dates usually being fixed
• For most projects it is hard to correctly make estimates across the different sequential phases for any sizable time frame

Software testing in sequential models are often subject to schedule compression. What is initially estimated may not be what is actually available or suffice for the testing team to complete its activities. When activities in any of the preceding phases of the chosen sequential model extend beyond estimates, it is often the case that towards the end of the project, the time available for testing gets cut back. Usually a trade-off between testing and delivery dates is necessitated. Often, the software testing group faces pressure to approve the release of the product by the delivery date even when the testing team has not received the time they originally estimated and planned for. However, when issues are reported from the field, the testing team is in the line of fire for not having caught all of these issues.

Schedule compression is not limited to the software testing team alone. Even product development teams face this issue. Schedule pressures can result in developers delivering poor quality artifacts to the testing team. Developer testing may be short-circuited too. The effect is that a considerable part of the testing time is spent on identifying, reporting and tracking defects that should not have been there in the first place. In such cases it may seem that the testing team is spending a considerable part of its time performing unit testing on the build that is delivered to the testing group rather than any higher level of testing which the team would have planned.

Sequential models require a fixed or near final set of requirements to be defined at the start of the project. Subsequent project phases including implementation and testing are based on the requirements defined at the outset of the project. Changes to the requirements will impact the testing group's plans. Any change will require the project to take a few steps back, incorporate the changes and be tested before moving ahead.

It is also the case that the testing team is not involved from the outset and testing is relegated towards its phase which is near the end of the software project lifecycle. There is little time for the testing group to be prepared. This will result in testing becoming purely reactive in nature with little scope for any preventive activities. The effectiveness and value of the testing team is reduced.

Effective test management can enable the group to handle the challenges mentioned above. In the next upcoming post we look at testing in the incremental and iterative models.