I recommend a testing approach that is risk-driven, leverages agile principles, encourages early validation and verification activities, reports progress with practical metrics, and is controlled through hand-offs and acceptance criteria overlaid on the development cycle via a scalable “V-model” (whether Agile, Iterative or Waterfall).
We can apply and tailor our test approaches to match an organization’s development and testing life-cycles, always keeping their project constraints and business goals in mind.
The “V-model” provides a rudimentary yet effective way to describe a software development lifecycle regardless of the organization’s or project team’s chosen methodology or processes.
A Scalable V-Model as a Tool
In the diagram below, the scalable model illustrated is used to facilitate discussion around the testing approach options.
In discussing the ability and need to scale the rigour of testing and which test planning and execution techniques can be employed, visibility is provided to the project team as to what challenges and risks that may exist for successfully assessing system quality – resulting in recommendations on how the test team will be able to maximize their contribution within the specific context of the project.
One crucial point to take from the V-model is the implication that the definition of the acceptance tests should be possible before test cases for technical testing are defined or code is written.
This encourages involvement and collaboration by all the parties early in the project when feedback regarding the scope of change could prevent serious issues later in the project cycle when it is much more expensive or even impossible to make changes – part of a “smart” approach to testing.
Finally, the V-model embodies the ability to describe and promote validation activities at multiple levels as well as verification.
Summary
Our recommended overall approach to testing is risk-driven (whether the project is Agile, Iterative or Waterfall) such that we examine the project and the system to be deployed for risks to system quality, risks to the test effort being successful within the context of the existing or assumed constraints, and any implied risks to the business/organization.
Using this risk-driven approach, we scale the level of formality and the depth or detail of the testing required for:
- Each area of the system
- Each phase of the project
- Each type of testing to be employed
Then we match the appropriate technique for testing to fit the predetermined need for formality and detail. Often the result is a hybrid of multiple techniques employed as the project progresses.
