It defines the relationships between the respective design and testing phases.
It improves the quality of software early in the Software Development Lifecycle (SDLC) by getting testing involved at a much earlier stage than would be the case using the waterfall model. For instance, UAT planning and scripting can begin as soon as the Business Requirements are approved; System Testing planning and scripting can begin as soon as the Functional Specification or design documents have been approved.
The beauty of testing early is that defects in specifications will be found sooner in the SDLC, meaning that they are not built into subsequent stages. This also applies to Business Requirement documents. The last stage of functional testing prior to promotion to the production environment is User Acceptance Testing (UAT). If UAT testers discover shortcomings in the requirements specification, i.e. the system doesn’t do what they (the business users) require, then changes may be requested to the requirements document. Subsequent code changes can be costly, especially if a lot of functionality has been based upon a requirement that is found wanting.
The bottom line is there is risk mitigation and potential cost savings to be made by beginning test planning early.
The left side of the V Model represents the design and development phases, also known as the verification phase whilst the right represents the testing phases, also known as the validation phase.
Verification can be defined as the process of evaluating a system or component to determine whether the products of the given development phase satisfy conditions imposed at the start of that phase (BS 7925-1).
Validation can be defined as determination of the correctness of the products of software development with respect to the user needs and requirements (BS 7925-1).
Design and testing phases are often depicted with different titles and even different stages. Here I shall use those specified in the ISEB syllabus.
Business Requirements
An organisation decides it has a requirement for a software development project. Business Analysts then create the Business Requirement document. Once this is approved it will be passed on to the development team. The user acceptance planning and Test Cases are created from the business requirement document as soon as it has been approved.
Project Specification
This document specifies how the system will be organised and what application interfaces there will be. Knowing this allows us to know which interfaces we need to test. We can plan and design the end to end Integration Testing in the large at this stage which will follow and validate data from start to finish across all applications.
System Specification
This is produced by the development team and describes the technical solutions to the business requirements. This may take the form of one or more technical documents. It is from this document or documents that the system tests are planned and created.
Design Specification
This the low level design of the system that has sufficient detail to allow developers to write their code. It is from this that the integration testing in the small Test Cases are created. This is where the interfaces of units of code are tested to ensure they function correctly together.
Code
This is the actual code that has been created in reference to the Design Specifications. Component Testing, or Unit Testing, is carried out by the developers against the individual blocks of code to ensure that they function as expected.
Posts
