Stellen Sie sich vor, Sie hätten einen neuen E-Scooter entwickelt und möchten jetzt herausfinden, ob er funktioniert und vor allem so, wie es Ihr Auftraggeber gewünscht hatte. Sie testen ihn also. Nach einer ersten Fahrt stellen Sie fest, dass er fährt, bremst und sich gut lenken lässt, aber die Akkuanzeige keinen Hinweis auf die aktuelle Restlaufzeit liefert. Schade, denn so weiß der Fahrer des Rollers ja gar nicht, wie weit er noch kommt.
Spezifikation
Was kann die Ursache für diesen Mangel sein? Unterschiedliche Gründe kommen infrage:
- Es gab keine Anforderung/ kein Anwendungsszenario für eine solche Anzeige.
- Es gab eine Anforderung, die fehlerhaft war.
- Es gab eine konsistente Anforderung, die aber nicht erfüllt wurde.
Im ersten Fall fehlt die Grundlage für eine Prüfung, im zweiten Fall ist die Grundlage fehlerhaft. Wo keine konkrete und korrekte Anforderung ist, kann auch deren Erfüllung nicht überprüft werden. Das heißt, für die Verifikation und Validierung ist es notwendig, dass eine Spezifizierung von Anforderungen, Nutzern, Nutzungskontext und Nutzungszielen stattgefunden hat. Im Falle von Software gibt es für die Spezifikation von Anforderungen genaue Vorgaben, z.B. in der Recommended Practice for Software Requirements Specification (SRS) IEEE 830 oder dem neueren Standard ISO/IEC/IEEE 29148:2011 Systems and Software Engineering – Life Cycle Processes – Requirements Engineering.
Qualitätskontrolle
Sowohl die Verifizierung als auch die Validierung sind Maßnahmen des Qualitätsmanagements. Dementsprechend werden beide Disziplinen in der Norm ISO 9000 behandelt. Weil bei komplexer Software allerdings oft nicht mehr alle Eventualitäten getestet werden können, kommen zunehmend Maßgaben des Risikomanagements ins Spiel. Stellen Sie sich vor, eine Medizintechnik-App soll Vitalfunktionen messen. Kann der Hersteller überhaupt noch garantieren, dass die Anwendung auf allen möglichen mobilen und nicht-mobilen Endgeräten und OS in unterschiedlichsten Versionen stabil läuft? Wohl kaum. Denn um alle möglichen Szenarien zu testen, müsste man sie ja alle erst einmal definieren. Das wäre ziemlich uferlos. Also ermittelt man Risiken, die im Kontext der Entwicklung auftreten können, bewertet sie und leitet Maßnahmen ab, um deren Eintrittswahrscheinlichkeit zu minimieren.
Ist das Produkt richtig gebaut?
Definition von Verifizierung laut ISO 9000:
Bestätigung durch einen objektiven Nachweis, dass Anforderungen erfüllt werden.
Die Verifikation soll feststellen, dass das Ergebnis einer Entwicklung konform zur Spezifikation ist. Im Software-Bereich kann die Verifizierung durch Testen (z.B. Modultest, Integrationstest, Systemtest) geleistet werden. Damit kann allerdings nicht nachgewiesen werden, dass das betrachtete Produkt fehlerfrei ist. Durch Prüfen von Falschem wird Falsches nicht richtiger.
Wird das richtige Produkt entwickelt?
Definition von Validierung laut ISO 9000:
Bestätigung durch objektiven Nachweis, dass die Anforderungen für eine bestimmte Anwendung oder einen bestimmten Gebrauch erfüllt sind.
Die Validierung überprüft die Eignung der Anforderungsdefinition mit den Zielen der Stakeholder. Oder einfacher: Sie prüft, ob das Produkt bietet, was der Nutzer braucht. Bei klassischem Vorgehen erfolgt sie meist erst in Form eines Abnahmetests. Auch diese Prüfung bedarf einer Grundlage, z.B. Szenarios mit Use Cases. Entscheidender Unterschied zur Verifikation ist die Interaktion mit einem Nutzer. Mögliche Validierungsinstrumente sind: Reviews, Prototypen, A/B-Tests, Usability-Tests etc.
Verifizierung ungleich Validierung
Es kann vorkommen, dass die Verfizierung eines Produkts erfolgreich ist, aber die Validierung nicht und umgekehrt. Denkbar wäre, dass der E-Scooter entsprechend der Spezifikation mit einem 200W Elektromotor ausgestattet ist (Verfizierung erfolgreich) und bis zu 20km/h beschleunigt (Zweckbestimmung), aber nicht (wie angenommen), wenn der Fahrer über 100 kg wiegt (Validierung gescheitert).
Umgekehrt könnte es sein, dass im E-Scooter nur ein 150W Elektromotor verbaut ist (Verfizierung gescheitert), der Roller bis zu 20km/h Leistung schafft (Zweckbestimmung) und Fahrer trotz eines Gewichts von über 100kg fahren können (Validierung erfolgreich).
Bei der Validierung kann man dann noch unterscheiden, ob ein Nutzungsziel überhaupt erreicht wird oder darüber hinaus das Nutzungsziel so umgesetzt ist, dass es den Nutzer von seinen Benefits überzeugt. Denn das möchte man ja schließlich mit der Entwicklung bezwecken: Usability, die begeistert und zum Kauf verleitet.
Erst verifizieren dann validieren?
Im klassischen V-Modell erfolgt die Validierung nach der Verifikation. Die Anforderungen werden in aufeinanderfolgenden Phasen für die Implementierung immer weiter verfeinert und dann ausgehend vom feingranularen Zustand auf Modulebene bis hin zum Test auf Systemebene verifiziert. Erst wenn die Verifikation abgeschlossen ist, nimmt man eine Validierung vor. Das ist übersichtlich und kausal, dauert aber oftmals viel zu lang.
Continuous Verification & Validation
Wie machen es die Agilen? Agile Teams verantworten das entwickelte Produkt einschließlich der Qualität. Die organisatorische Trennung von Entwicklung, Qualitätsmanagement und IT-Betrieb mit definierten Übergabepunkten ist im agilen Umfeld nicht praktikabel. Stattdessen kann man unterscheiden in Testen innerhalb und außerhalb des Teams. Das Testen der Anforderungen innerhalb des autonomen Entwicklungsteams könnte man auch verifizieren nennen. Das Testen außerhalb des Teams zur Evaluation der Nutzung und der fachlichen Qualität validieren. Innerhalb des Teams sollte man zwischen fachlichen Qualitätsanforderungen und der technischen Umsetzungsqualität differenzieren. Der Product Owner legt (eventuell zusammen mit Stakeholdern und Team) Akzeptanzkriterien fest und das Team verantwortet die Realisierung. Die Rolle eines externen Qualitätsmanagers ist z.B. bei Scrum nicht vorgesehen, aber immer häufiger findet man Entwickler im Team mit Tester-Fachwissen, die das Team bei Unit-Tests und Testautomatisierung unterstützen statt überwachen sollen.
Weil es keine feststehende, abgeschlossene Spezifikation als Grundlage für die Entwicklung gibt, wird kontinuierlich verifiziert und validiert. Produktinkremente werden ausgeliefert und sorgen für aktuelles Feedback über die reale Nutzung. DevOps, Testautomatisierung, Test-Driven-Development, Continuous Integration und Delivery sind alles Maßnahmen, um kontinuierlich Zwischenergebnisse zu erhalten und einem Scheitern am Ende durch erfolglose Validierung vorzubeugen. Je früher Fehler entdeckt werden, desto zeitiger und günstiger können sie behoben werden. Das besagt ja auch schon die Rule of Ten: Fehlerkosten für einen nicht entdeckten Fehler erhöhen sich von Stufe zu Stufe der Wertschöpfung um den Faktor 10.
Die Spezi muss spitze sein
Was hilft also, um Fehler rechtzeitig zu entdecken und zu beheben? Egal ob klassisch oder agil entwickelt wird, letztlich spielen aktuelle, präzise, eindeutige, verständliche und vollständige Anforderungen die entscheidende Rolle. Je öfter diese sich ändern, desto leichter verliert man deren Spur. Darum entwickeln wir Software, die Ihnen die Traceability, Verifikation und Validierung so ermöglicht, wie Sie es brauchen, um Qualität zu sichern. Lesen Sie hier mehr über Traceability mit objectiF RM und objectiF RPM.