Why DVP&R Processes Often Fail Before the First Test Begins

The test bench is booked, the vehicle is ready, and the measurement equipment has been prepared. In theory, testing can begin.

Then someone asks: Is this really the latest test request?

Another question follows: Has the most recent vehicle change already been taken into account? And which version of the test specification is actually valid?

Problems in vehicle testing often do not begin during the test itself. They begin earlier — in planning.

A Design Verification Plan and Report, or DVP&R, is intended to define what needs to be verified and connect those verification activities with their results. Its real value lies in maintaining a continuous relationship between requirements, tests, test objects, and evidence.

The larger a development program becomes, however, the harder it is to preserve those relationships using files, spreadsheets, and manual coordination alone.

The real problem is therefore not the individual Excel file. It is expecting a file to represent a process that is constantly changing.

A test plan is not a static document

In a small project, a spreadsheet can work remarkably well. A limited number of people know the vehicles, communicate directly, and usually know which version is current.

Large testing programs are different.

Tests run in parallel across several locations. Vehicle configurations change. Tests depend on one another. Test benches become unavailable or are reassigned. Test objects are modified. Results create issues, and new findings affect subsequent planning.

Under these conditions, a DVP&R has to do more than store test names and status fields in rows.

It has to preserve relationships.

A test relates to a requirement. It is performed on a specific vehicle or component. That test object has a particular build, hardware configuration, and software version. Resources are needed to perform the test. Specific procedures and specifications apply. The test produces measurement data, observations, assessments, and potentially issues.

Months later, it should still be possible to understand exactly under which conditions a particular result was produced.

A spreadsheet does not inherently understand any of these relationships. It contains values in cells. Their meaning is created by the people who know how those values fit together.

As the number of tests, systems, and participants increases, that human knowledge becomes a bottleneck.

Version problems are only the visible symptom

When several teams work on a shared verification plan, uncertainty often starts with a simple question:

Which version is current?

But that is only the visible part of the problem.

The more important question is whether the verification plan still reflects the actual state of testing.

A test specification may have changed while an already scheduled test still refers to the previous version. A vehicle may have been modified. An unresolved issue may prevent further testing. A test bench may become unavailable. A preceding test may be delayed.

Every one of these changes can affect the DVP&R.

In a file-based process, people have to recognize those consequences and manually update the relevant places. The original change may exist in a test-bench scheduling system, its consequence may appear in the DVP, the affected vehicle configuration may be stored somewhere else, and the corresponding issue may sit in yet another system.

The DVP&R shows a status.

The context behind that status is distributed across multiple systems.

That becomes critical when decisions are based on the information. A high test-completion percentage tells only part of the story if some results were generated using an outdated vehicle configuration or specification, or if important requirements remain insufficiently covered.

Dependencies belong in the process

Tests rarely exist in isolation.

One test may only begin after another has been completed successfully. A destructive test may have to take place at the end of a sequence. A vehicle can only be used in one location at a time. A particular software version may be required. A measurement system must be available and configured correctly.

In conventional verification plans, these dependencies are often represented through row order, comments, or separately maintained schedules.

That works as long as experienced employees keep the consequences in their heads.

Machine-readable relationships change the process.

If the system knows that Test B depends on Test A, a change to Test A can immediately become visible in the context of Test B. If a test vehicle is linked to its current configuration, modifications, and open issues, its suitability for a planned test no longer has to be reconstructed manually from several sources.

The verification plan becomes more than a list.

It becomes a connected model of the testing process.

The report should grow as testing takes place

Another problem is already hidden in the name DVP&R.

In many organizations, the plan and the report are treated as separate activities. First, the verification plan is created. Tests are performed later. Toward the end of the project, results have to be collected, status information updated, approvals traced, and evidence assembled.

That creates considerable additional work precisely when the project is approaching completion.

Yet much of the required information already exists during test execution.

Which test request was performed? Which test object was used? Which specification applied? Which files were generated? What result was recorded? Who assessed or approved it?

If these pieces of information are connected from the beginning, the report grows together with the testing process. Evidence does not have to be reconstructed afterward from several different systems.

For test engineers, that means less time spent reconstructing what happened.

For project managers, it provides a more reliable view of the actual verification status.

Test management systems instead of another isolated database

A central test management platform does not necessarily have to replace every existing system.

With Cluu Assisted Testing, we take a different approach. Information from existing IT systems can be connected and used within a shared technical context.

Test requests, vehicles, test objects, measurement points, sensors, measurement devices, data loggers, measurement files, observations, and issues are not treated as isolated records.

The relationships between them become part of the process.

A test request can therefore be followed from feasibility and planning through execution to completion. Measurement data can be linked to its metadata and corresponding test context. Changes can be historized, while relevant activities remain traceable.

Existing systems can continue to be used and connected through interfaces and adapters instead of creating another parallel repository for every piece of information.

This is particularly important in organizations whose IT landscapes have evolved over many years.

In automotive testing, that is the rule rather than the exception.

Excel is not the real problem

Blaming Excel for the problems of complex testing processes would be too simplistic.

A spreadsheet is excellent for flexibly presenting and editing structured information. But it cannot know by itself that the software version of a test vehicle has changed, that a measurement file belongs to a particular test, or that one delayed test is blocking three subsequent activities.

Those relationships have to be established either by people or by a system.

That is why digitizing the DVP&R should not begin with the question:

How can we reproduce the existing spreadsheet more elegantly in software?

A more useful question is:

Which relationships have to remain intact throughout the testing process so that planning, execution, and results still fit together months later?

Once those relationships are represented digitally, the result is more than an electronic verification plan.

Individual tests become part of a connected testing process.

‍