Multiple V-model in relation to testing

Sogeti Nederland B.V.

Edwin Notenboom
[email protected]

In embedded systems, the test object is not The test process involves a huge number of
just executable code. The system is usually developed test activities. There are many test design techniques
in a sequence of product-appearances that become that can and will be applied, test levels and test types
more real. First a model of the system is built on a PC, that must be executed, and test related issues that
which simulates the required system behavior. When require attention. The multiple V-model assists in
the model is found to be correct, code is generated structuring these activities and issues. By mapping
from the model and embedded in a prototype. The them onto the multiple Vs, it provides insight to the
experimental hardware of the prototypes is gradually questions: "When can activities best be executed?"
replaced by the real hardware, until the system is built "Which test issues are most relevant at which stage in
in its final form as it will be used and mass produced. the development process?"
The reason for building those intermediate product- Organising the testing in the complex situation
appearances is, of course, that it is cheaper and quicker of multiple V-model development is itself a complex
to change a prototype than to change the final product, task. In order to plan and manage this well, the test
and even cheaper and quicker to change the model. manager needs an overall picture of all relevant test
The multiple V-model, based on the well- activities and issues onto the multiple Vs. It takes a
known V-model is a development model that takes this broad range of activities and issues that are to be
phenomenon into account. In principle each of the considered. They are in alphabetical order and divided
product appearances (model, prototypes, final product) into three categories: test techniques; test levels and
follows a complete V-development cycle, including types; and other issues. Each is then put on one or more
design , build and test activities. Hence the term Vs at the relevant stage of that V. It is possible for
'multiple V-model' (see Figure 1). The essence of the certain issues, such as low-level requirements, to
multiple V-model is that different physical versions of appear in the V for the model as well as in the V for the
the same system are developed, each possessing the prototype.
same required functionality in principle. This means, The multiple V-model with the three
for instance, that the complete functionality can be sequential V-cycles does not take into account the
tested on the final product. On the other hand, certain practice of (functional) decomposition of a complex
detailed technical properties cannot be tested very well system. The development of such a system starts with
on the model and must be tested on the prototype - for the specification of the requirements at a high-level,
instance, the impact of environmental conditions can followed by an architectural design phase where it is
best be tested on the final product. Testing the different determined which components (hardware and software)
physical versions often requires specific techniques and are required to realise this. Those components are then
a specific test environment. Therefore a clear relation developed separately and finally integrated into a full
exists between the multiple V-model and the various system. In fact the simple V-model can be applied to
test environments. this development process at a high-level. The left side
of the V-model handles the decomposition of the
system into its components. The middle
part of the V-model handles the
Model Prototype Final product decomposition of the system into its
components. The right side of the V-
model handles the integration of the
des

test

des

test
ign

des

components.
test
ig

ign
n

This principle can be repeated

build
for components that are too big or too
build complex to develop as one entity. For
simulation stage
build such a component, an architectural design
post-development stage activity is carried out to determine which
prototyping stage subcomponents are required. Because this
may result in a V-model within a V-
pre-production stage
model the development lifecycle model is
said to be nested.
In fact the purely sequential multiple V-model
Figure 1: Multiple V-development lifecycle
is mainly applicable to the component level. Usually it
is not the complete system which is fully modeled first, The development of a system containing
then completely prototyped, and so on. It is the embedded software involves many test activities at
components that are built in this stepwise way. This different stages in the development process, each
explains why some development activities and issues requiring specific test facilities. Some organisations
cannot be mapped very well on the 3 Vs in the multiple have a testing process divided into test as shown in
V-model - for instance high-level and low-level figure 3. This can be mapped onto the development
requirements, safety plan, design and build specific stages (see Figure 1). The early models developed to
tools. That is because they belong to the overall simulate the system are tested in 'model tests' (MT) and
development process. 'model-in-the-loop' (MiL) - this corresponds to the
When the V-model at the system level is simulation stage. In 'rapid prototyping' (RP) an
combined with the multiple V-model at the component experimental model with high performance capacity
level, it results in the so-called 'nested multiple V- and plenty of resources is tried out in a real-life
model' (see Figure 2). environment to check if the system can fulfill its
purpose - this is also part of the simulation stage. In
'software-in-the-loop' testing (SiL) the real software
Master test plan Release advise including all resource restrictions is tested in a
Safety plan Real life test
simulated environment or with experimental hardware.
In 'hardware-in-the-loop' testing (HiL) the real
System integration test hardware is used and tested in a simulated environment
- both 'SiL' and 'HiL' are part of the prototyping stage.
In 'system test (ST) the real system is tested in its real
environment - this corresponds to the pre-production
stage.

Detailed test plan

Legal requirements
Design & build tools; simulators; stubs; drivers

MT / MiL
simulation
stage

Figure 2: Higher level test issues in the nested

multiple-V model RP Sil

If every test level would define for itself the

best things to do, there would be a significant risk that prototyping
some tests would be performed twice and others would MT = model test stage
be omitted. In practice, it is not unusual for the system MiL = model in the loop
Hil
RP = rapid prototyping
test and the acceptance test to have the same test design SiL = software in the loop
techniques applied to the same system specification - HiL = hardware in the loop
ST = system test
this is a waste of valuable resources. Another risk is pre-production
ST stage
that the total test process, spends longer on the critical
path than is necessary because the planning of the
different test levels has not been coordinated. Of course
it is better to coordinate the various levels: it prevents
Figure 3: A test process showing the gradual
redundancies and omissions; it ensures that a coherent
transitions from “simulated” to “real” system
overall test strategy will be implemented. Decisions
must be made as to which test level is most suited to
testing which system requirements and quality
attributes.
A master test plan can be viewed as the
combination of what has to be tested and who is going
to perform the test activities. After completing the
master test plan, for each test level the staff involved
will know exactly what is expected of them and what
level of support and resources they can expect. The
master test plan serves as the basis for the detailed test
plan of each test level.