The right arm of the V-model - not just testing

The V-model plays a prominent role in systems engineering: it is both a process model and an information model, which starts at the top left with the requirements in order to reach the implementation at the bottom center. The right arm represents the verification and validation activities. These are often, but not always, tests. There are more things that are important when looking at the right arm of the V.

About the many misunderstandings around the V-model I had already written about this. There are various methodical approaches as to how we can best deal with this.

We tend to focus more on the left part of the V, and understand it better. This is not really surprising, as testing is often an afterthought, for two reasons: First, testing doesn't seem as critical as development, as this is often not a deliverable to the customer that is required for operations. However, increasingly stringent compliance requirements are changing this.

Secondly, V&V activities are only possible once the associated left-hand side of the V exists, which means that these are inevitably downstream and, in the worst case, are ignored for time or budget reasons.

V&V

Validate and verify - what exactly is the difference? There are many good explanations for the difference, like these for example.

Validate: Building the right thing.
Verify: Build the thing properly.

When validating, we want to ensure that we are building what is actually needed. Verification, on the other hand, is about correct technical implementation.

Traceability - in which direction?

If we look at the cover image, we see two arrows that relate to the right arm of the V. The arrow from the bottom center to the top right is not actually an important traceability relationship, but merely corresponds to the temporal sequence, i.e. in relation to the process model. And even this can be misleading, as the different levels can be decoupled from each other.

Much more important for traceability are the horizontal arrows, which represent the "tests" relationships: The tests on the right-hand side test the requirements on the left-hand side. Sometimes the arrow is also drawn in the other direction. Then it means "is tested by". In this case, the direction also better shows the effects of changes: If the requirement is changed, the test must be checked and perhaps adapted.

The relationship between requirements and tests makes sense in both directions: from right to left it is the "test" relationship, from left to right the "impact" relationship.

However, a relationship between the tests, as suggested by the process arrow, is almost never meaningful or useful.

Not just testing for V&V

When we think of V&V activities, we often think of testing. It should be noted that there are many different types of tests, for example:

• Unit Test
• Integration test
• Hardware-in-the-loop test
• Acceptance test
• Usability test
• Regeression test
• System test
• Beta test

But there are numerous alternatives for testing, for example:

• Analysis
• Review
• Simulation
• Prototypes & Mock-ups
• Surveys
• MVPs
• Formal proofs
• Asserts
• Models

Other activities in the right arm

As Yordan mentioned in the comments, there are other activities taking place in the right arm of the V beyond V&V, such as the integration of the system.

Get better

There is currently a lot of interest in the market for V&V activities, as these are a way of getting to grips with the exploding complexity in systems engineering. There are four measures with which we can quickly achieve better results:

• Define tests at an early stage - Defining tests also helps to improve the requirements. Especially with modern tools, it is easy to develop requirements and tests together.
• Carry out tests at an early stage - Not always easy, but the earlier tests are carried out, the earlier we get feedback. The higher we move up the right-hand side of the V, the more difficult this becomes, of course. After all, we can't really test without a complete product. However, alternatives to testing can be used here, such as prototypes, mock-ups or models.
• Test frequently - This is actually only possible if the test activities are automated. This has become common practice in software development in particular, but is Hardware but also possible.
• Use alternatives for testing - The list above already shows a number of alternatives. It makes sense to regularly question whether testing is really the best way.