Warum DVP&R-Prozesse häufig scheitern, noch bevor der erste Test startet

Der Prüfstand ist reserviert, das Fahrzeug steht bereit und die Messtechnik ist eingerichtet. Eigentlich kann es losgehen. Doch dann kommt die erste Frage auf: Ist das tatsächlich der aktuelle Prüfauftrag? Gleich danach folgt die nächste: Ist die letzte Änderung am Fahrzeug schon berücksichtigt? Und welche Version der Testspezifikation ist überhaupt gültig?

Probleme in der Fahrzeugerprobung entstehen oft lange vor dem eigentlichen Test. Ihre Ursache liegt häufig schon in der Planung.

Ein Design Verification Plan and Report, kurz DVP&R, definiert, was geprüft werden soll, und verknüpft die späteren Ergebnisse mit den jeweiligen Prüfaktivitäten. Sein eigentlicher Nutzen entsteht damit durch die lückenlose Verbindung von Anforderungen, Prüfungen und Ergebnissen. Je umfangreicher ein Entwicklungsprogramm wird, desto schwieriger wird es jedoch, diese Beziehungen mit Dateien, Tabellen und manuellen Abstimmungen zuverlässig aufrechtzuerhalten.

Das eigentliche Problem ist daher selten eine einzelne Excel-Datei. Kritisch wird vielmehr die Annahme, dass eine Datei einen Prozess abbilden kann, der sich laufend verändert.

Ein Prüfplan ist mehr als ein statisches Dokument

In einem überschaubaren Projekt kann eine Tabelle erstaunlich gut ihren Zweck erfüllen. Die wenigen Beteiligten kennen die Fahrzeuge, stimmen sich direkt ab und wissen in der Regel, welcher Stand gerade aktuell ist.

Bei einem großen Erprobungsprogramm sieht das schnell anders aus. Prüfungen finden parallel an mehreren Standorten statt. Fahrzeugstände verändern sich. Manche Versuche setzen andere voraus. Prüfstände fallen aus oder werden kurzfristig anders eingeplant. Testobjekte werden umgebaut. Ergebnisse führen zu Beanstandungen, während neue Erkenntnisse gleichzeitig die weitere Planung beeinflussen.

Unter solchen Bedingungen muss ein DVP&R deutlich mehr können, als lediglich Testnamen und Statusfelder in Zeilen abzulegen.

Er muss die Zusammenhänge bewahren.

Jede Prüfung ist einer Anforderung zugeordnet. Sie findet an einem bestimmten Fahrzeug oder Bauteil statt. Dieses Testobjekt weist einen konkreten Bau-, Hard- und Softwarestand auf. Für die Durchführung braucht es bestimmte Ressourcen. Gleichzeitig gelten definierte Prüfvorschriften. Während des Tests entstehen Messdaten, Beobachtungen, Bewertungen und gegebenenfalls Issues. Auch später muss noch erkennbar sein, unter welchen Bedingungen ein bestimmtes Ergebnis entstanden ist.

Eine Tabelle bildet solche Beziehungen von sich aus nicht ab. Zunächst stehen dort lediglich Werte in einzelnen Zellen. Ihre tatsächliche Bedeutung entsteht erst durch die Menschen, die wissen, wie diese Angaben miteinander verbunden sind.

Je mehr Tests hinzukommen, desto stärker wird genau dieses Wissen zum Engpass.

Versionsprobleme sind lediglich das sichtbare Symptom

Sobald mehrere Teams gemeinsam an einem Prüfplan arbeiten, beginnt die Unsicherheit häufig mit einer scheinbar einfachen Frage: Welche Version ist eigentlich die aktuelle?

Doch das ist nur der sichtbare Teil des Problems.

Entscheidender ist, ob der Prüfplan den realen Stand der Erprobung überhaupt noch korrekt widerspiegelt. Vielleicht wurde eine Testspezifikation angepasst, während ein bereits eingeplanter Versuch noch auf der vorherigen Fassung beruht. Ein Fahrzeug wurde inzwischen umgebaut. Eine Beanstandung verhindert weitere Versuche. Ein Prüfstand steht plötzlich nicht zur Verfügung. Oder ein vorgeschalteter Test verschiebt sich.

Jede dieser Änderungen wirkt sich auf den DVP&R aus.

In einem dateibasierten Prozess müssen Menschen diese Folgen zunächst erkennen und anschließend an allen relevanten Stellen einpflegen. Die eigentliche Ursache steckt möglicherweise im Kalender eines Prüfstands, ihre Auswirkung erscheint im DVP, der betroffene Fahrzeugstand wird in einem anderen System geführt und die zugehörige Beanstandung liegt wiederum in einem Issue Tracker.

Der DVP&R zeigt dann zwar einen Status an. Der Kontext, der diesen Status erklärt, verteilt sich jedoch auf mehrere Systeme.

Problematisch wird das spätestens dann, wenn auf dieser Grundlage Entscheidungen getroffen werden. Ein scheinbar hoher Erfüllungsgrad ist nur begrenzt aussagekräftig, wenn einzelne Ergebnisse auf einem inzwischen veralteten Fahrzeug- oder Spezifikationsstand beruhen oder zentrale Anforderungen noch nicht vollständig abgedeckt wurden. Genau darauf weist auch der Ausgangsartikel hin: Ein manuell gepflegter Plan kann auf dem Papier aktuell aussehen, obwohl sich die tatsächliche Testsituation längst weiterentwickelt hat.

Abhängigkeiten müssen Teil des Prozesses sein

Tests existieren nur selten unabhängig voneinander.

Ein Versuch kann beispielsweise erst starten, nachdem ein anderer erfolgreich beendet wurde. Ein zerstörender Test gehört möglicherweise zwingend ans Ende einer Versuchsreihe. Ein Fahrzeug lässt sich zur gleichen Zeit nur an einem Standort einsetzen. Eine bestimmte Softwareversion muss installiert sein. Auch ein Messsystem muss verfügbar und korrekt konfiguriert werden.

In klassischen Prüfplänen werden solche Abhängigkeiten oft über Reihenfolgen, Kommentare oder separat gepflegte Terminpläne dargestellt. Solange erfahrene Mitarbeiter die daraus entstehenden Konsequenzen im Kopf behalten, kann das funktionieren.

Maschinenlesbare Beziehungen ändern diesen Ablauf grundlegend.

Weiß das System, dass Test B von Test A abhängig ist, wird eine Änderung an Test A direkt im Zusammenhang mit Test B sichtbar. Ist ein Versuchsfahrzeug zudem mit seinem aktuellen Zustand, seinen Umbauten und offenen Beanstandungen verknüpft, muss seine Eignung für einen geplanten Test nicht jedes Mal mühsam aus mehreren Quellen zusammengesucht werden.

Aus einer reinen Liste wird so ein vernetztes Modell der gesamten Erprobung.

Der Report sollte bereits während des Tests entstehen

Ein weiteres grundlegendes Problem steckt schon in der Bezeichnung DVP&R.

Organisatorisch werden Plan und Report oft wie zwei getrennte Aufgaben behandelt. Zuerst wird der Prüfplan erstellt. Danach folgen die Tests. Erst gegen Projektende werden Ergebnisse zusammengetragen, Statusinformationen aktualisiert, Freigaben geprüft und Nachweise zusammengestellt.

Gerade zum Projektabschluss entsteht dadurch noch einmal ein erheblicher zusätzlicher Aufwand.

Viele der benötigten Informationen sind allerdings schon während der Durchführung vorhanden.

Welcher Auftrag wurde tatsächlich ausgeführt? Welches Testobjekt kam zum Einsatz? Welche Spezifikation war gültig? Welche Dateien wurden erzeugt? Zu welchem Ergebnis führte der Test? Und wer hat dieses Ergebnis bewertet oder freigegeben?

Werden diese Informationen von Beginn an miteinander verknüpft, entsteht der Report Schritt für Schritt gemeinsam mit dem Prozess. Der Nachweis muss dann später nicht aufwendig aus verschiedenen Systemen zusammengesetzt werden. Auch der Referenzartikel greift diesen Ansatz auf: Das „R“ im DVP&R wächst kontinuierlich mit, wenn Ergebnisse unmittelbar mit der jeweiligen Verifikationsaktivität und ihrem Kontext verbunden sind.

Für Testingenieure reduziert das vor allem die spätere Rekonstruktionsarbeit. Projektverantwortliche erhalten gleichzeitig ein verlässlicheres Bild davon, wie weit die Verifikation tatsächlich fortgeschritten ist.

Connected Testing statt einer weiteren zusätzlichen Datenbank

Eine zentrale Testmanagement-Plattform muss dafür nicht automatisch sämtliche vorhandenen Systeme ablösen.

Bei Cluu Assisted Testing setzen wir auf einen anderen Ansatz. Daten aus vorhandenen IT-Systemen lassen sich miteinander verknüpfen und in einem gemeinsamen fachlichen Zusammenhang nutzen. Prüfauftrag, Fahrzeug, Testobjekt, Messpunkt, Sensor, Messgerät, Data Logger, Messdatei, Beobachtung und Beanstandung stehen dadurch nicht länger als voneinander getrennte Datensätze nebeneinander.

Ihre Beziehungen untereinander werden selbst zum Bestandteil des Prozesses.

Auf diese Weise lässt sich ein Testauftrag von der Machbarkeit über die Planung und Durchführung bis hin zum Abschluss durchgängig verfolgen. Messdaten können mit Metadaten und dem jeweiligen Testkontext verknüpft werden. Änderungen lassen sich historisieren, während relevante Vorgänge dauerhaft nachvollziehbar dokumentiert bleiben. Bestehende Systeme können zugleich über Schnittstellen und Adapter eingebunden werden, anstatt für jede Information eine zusätzliche parallele Datenhaltung aufzubauen.

Gerade in über Jahre gewachsenen Tool-Landschaften ist dieser Punkt besonders wichtig. In der Fahrzeugerprobung sind solche Strukturen eher der Normalfall als eine Ausnahme.

Der DVP&R scheitert nicht wegen Excel

Excel allein für die Schwierigkeiten komplexer Erprobungsprozesse verantwortlich zu machen, greift zu kurz.

Eine Tabellenkalkulation eignet sich hervorragend dazu, strukturierte Informationen flexibel aufzubereiten und zu bearbeiten. Sie erkennt jedoch nicht eigenständig, dass sich der Softwarestand eines Versuchsfahrzeugs verändert hat, eine Messdatei einem konkreten Versuch zugeordnet ist oder ein verspäteter Test drei weitere Aktivitäten blockiert.

Entweder stellen Menschen diese Verbindungen her – oder ein System übernimmt diese Aufgabe.

Die Digitalisierung des DVP&R beginnt deshalb nicht bei der Frage, wie sich die bestehende Tabelle möglichst originalgetreu in einer Software nachbauen lässt. Entscheidend ist vielmehr: Welche Beziehungen müssen über den gesamten Erprobungsprozess hinweg erhalten bleiben, damit Planung, Durchführung und Ergebnis selbst Monate später noch eindeutig und nachvollziehbar zusammenpassen?

Wer genau diese Beziehungen digital abbildet, bekommt weit mehr als nur einen elektronischen Prüfplan.

Aus vielen einzelnen Tests wird ein durchgängiger, zusammenhängender Erprobungsprozess.