Der rechte Arm des V – Nicht nur Testen

Das V-Modell hat im Systems Engineering eine prominente Rolle: Es handelt sich dabei sowohl um ein Prozess- als auch ein Informationsmodell, welches von links oben mit den Anforderungen beginnt, um unten in der Mitte die Implementierung zu erreichen. Der rechte Arm stellt die Verifikations- und Validierungsaktivitäten dar. Das sind häufig, aber nicht immer Tests. Es gibt noch mehr Dinge, die beim Betrachten des rechten Arms des V wichtig sind.

Über die vielen Missverständnisse rund um das V-Model hatte ich bereits geschrieben. Es gibt verschiedene methodische Vorgehen, wie wir am besten damit umgehen.

Tendenziell beschäftigen wir uns stärker mit dem linken Teil des V, und verstehen dies auch besser. Das ist nicht wirklich verwunderlich, denn das Testen ist oft ein nachgelagerter Gedanke, aus zwei Gründen: Erstens erscheint das Testen nicht so kritisch wie die Entwicklung, da dies oft kein an den Kunden auslieferbares, für den Betrieb erforderliches Ergebnis ist. Durch immer schärfere Compliance-Anforderungen ändert sich dies allerdings.

Zweitens sind V&V-Aktivitäten erst dann möglich, wenn der dazugehörige linke Teil das V existiert, wodurch diese zwangsläufig nachgelagert und im schlimmsten Fall aus Zeit- oder Budgetgründen unterschlagen werden.

V&V

Validieren und verifizieren – was ist genau der Unterschied? Zum Unterschied gibt es viele gute Erklärungen, wie diese zum Beispiel.

Validieren: Das richtige Ding bauen.
Verifizieren: Das Ding richtig bauen.

Beim Validieren wollen wir sicherstellen, dass wir das bauen, was auch wirklich gebraucht wird. Beim Verifizieren hingegen geht es um eine korrekte technische Umsetzung.

Traceability – in welche Richtung?

Wenn wir uns das Titelbild anschauen, so sehen wir zwei Pfeile, die den rechten Arm des V betreffen. Der Pfeil von der Mitte unten bis nach rechts oben ist eigentlich keine wichtige Traceability-Beziehung, sondern entspricht lediglich dem zeitlichen Ablauf, also in Bezug auf das Prozessmodell. Und selbst das kann irreführend sein, da die verschiedenen Ebenen voneinander entkoppelt sein können.

Für die Traceability viel wichtiger sind die horizontalen Pfeile, welche die „testet“-Beziehungen darstellt: Die Tests auf der rechten Seite testen die Anforderungen auf der linken Seite. Manchmal wird der Pfeil auch in die andere Richtung gezeichnet. Dann bedeutet dieser „wird getestet von“. In dem Fall zeigt die Richtung auch besser die Auswirkungen von Änderungen: Wird die Anforderung geändert, muss der Test überprüft, und vielleicht angepasst werden.

Die Beziehung zwischen Anforderungen und Tests ist in beide Richtungen sinnvoll: Von rechts nach links ist es die „Test“-Beziehung, von links nach rechts die „Impakt“-Beziehung.

Eine Beziehung zwischen den Tests, wie von dem Prozesspfeil suggeriert, ist hingegen fast nie sinnvoll oder nützlich.

Nicht nur Testen für V&V

Bei V&V-Aktivitäten denken wir oft ans Testen. Dabei ist zu beachten, dass es viele verschiedene Arten von Tests gibt, zum Beipsiel:

• Unit Test
• Integrationstest
• Hardware-in-the-loop Test
• Akzeptanztest
• Usabilitytest
• Regeressionstest
• Systemtest
• Beta-Test

Doch es gibt zahlreiche Alternativen zum Testen, zum Beispiel:

• Analyse
• Review
• Simulation
• Prototypen & Mock-ups
• Umfragen
• MVPs
• Formale Beweise
• Asserts
• Modelle

Andere Aktivitäten im rechten Arm

Wie Yordan in den Kommentaren bereits erwähnte, so finden im rechten Arm des Vs auch noch andere Aktivitäten jenseits von V&V statt, wie bspw. die Integration des Systems.

Besser werden

Aktuell ist viel Interesse im Markt an V&V-Aktivitäten, da diese einWeg sind, um die explodierende Komplexität im Systems Engineering in den Griff zu bekommen. Dabei gibt es vier Maßnahmen, mit denen wir schnell bessere Ergebnisse bekommen:

• Frühzeitig Tests definieren – Das definieren von Testen hilft, die Anforderungen ebenfalls zu verbessern. Gerade mit modernen Werkzeugen ist es leicht, Anforderungen und Tests zusammen zu entwickeln.
• Frühzeitig Tests durchführen – Nicht immer einfach, aber je früher Tests durchgeführt werden, desto früher bekommen wir eine Rückmeldung. Je höher wir auf der rechten Seite im V uns bewegen, desto schwerer wird dies natürlich. Denn ohne ein entsprechend vollständiges Produkt können wir ja nicht wirklich testen. Doch hier können alternativen zum Testen eingesetzt werden, wie bspw. Prototypen, Mock-ups oder Modelle.
• Häufig testen – Dies ist eigentlich nur möglich, wenn die testaktivitäten automatisiert werden. Insbesondere in der Softwareentwicklung ist dies inzwischen üblich, ist mit Hardware aber ebenso möglich.
• Alternativen zum Testen einsetzen – Die Liste oben zeigt ja bereits eine Anzahl von Alternativen auf. Es ist sinnvoll regelmäßig zu hinterfragen, ob Testen wirklich der beste Weg ist.