The V Model
The V-Model has proven very popular over recent years and has probably replaced the Waterfall Model as the established model of software development. It is interesting to consider that the V-Model could not have existed without the prior experiences gained from usage of the Waterfall Model. If the Waterfall Model is the stern father then the V-Model is the popular son. Delve deeper into its usage and application, however, and one sees that it is not a panacea for all software development ills. Consider the representation of the V-Model below:
You can take the V-Model as a Waterfall Model snapped in the middle and bent upwards. You then have two 'stalks'; in ...view middle of the document...
This is where the V-Model is useful because it maps the design phase to its associated test phase. As soon as the project starts, testers should be participating in the review of the SOUP and communicating with the customer or customer's representative. Viewing the SOUP in consideration of its 'testability' will mean that better User Acceptance Tests can be written by the testers. These tests should reflect that the UAT phase is one of validation rather then verification, making UAT phase different from all other test phases. Here, the question being asked is 'did we build the right thing?' rather than 'did we build it right?' At the end of the SOUP phase, the SOUP documentation should be reviewed, approved and signed-off. This constitutes part of the milestone between exiting this phase and entering the Specify Requirements phase. As time progresses thereafter, the UAT documentation should be firmed up. Naturally, there may be changes to the SOUP after its initial approval and these should be reviewed and acted upon by the testers once they are approved.
The UAT phase is run in a production or production-like environment (it may even be on the customer's site). Although the UAT tests are normally authored by testers (in conjunction with customers or customer representatives) they should be run by customers or approved customer-representatives. Either way, the people who execute the UAT tests should have a very detailed knowledge of the business domain the software is used within. As a matter of preparation, UAT testers should be trained in the correct way to raise and report upon any issues found. As the start of the UAT phase approaches, entry criteria should require that the UAT documentation is up-to-date, approved and signed-off. A UAT Reprt is normally produced at the conclusion of this test phase.
Specify Requirements & Release Test Phases
Once the customer's needs have been clearly understood and documented in the SOUP then work can start on the Requirements Specification. There should be a formal milestone review between exiting the SOUP phase and entering the Specify Requirements phase. In this sense, the V-Model is no different from the Waterfall Model. Testers should participate in reviewing the Requirements Specification right from the start, and should make reference to the preceding SOUP. Since traceability is a key aspect of testing, the requirements should trace back to the SOUP to maintain traceability. Similarly, there should be traceability between the Release Test documentation and the Requirements Specification. In planning the Release Test, testers should consider non-functional as well as functional requirements. Furthermore, not only explicit requirements should be considered but implicit requirements too. Thinking like this can often lead the testers to ask questions which result in original requirements being modified or enhanced. Again, as time progresses, all changes should be reflected in the Requirements...