Damit ein Projekt wirtschaftlich und planbar ist, ist ein Projektplan mit einer definierten Zeitachse auch für die Entwicklung im regulierten Umfeld unabdingbar, egal, ob agil oder nach dem Wasserfallmodell entwickelt wird. Die Projektleitung steht bereits zu Beginn der Entwicklung zusammen mit dem Testmanager vor der Herausforderung, die Aufwände für die Verifizierung richtig einzuschätzen und einzuplanen. Häufig zeigt sich die Projektleitung zu Beginn großzügig hinsichtlich von essentiellen Phasen für die Verifizierung (z.B. explorative Testphase, Probeverifizierung). Im Verlauf der Entwicklung und insbesondre bei Verzögerung der Entwicklung werden aber diese Aufwende im besten Fall in Frage gestellt, parallelisiert oder gar gestrichen. Die hierdurch entstehenden Probleme und Projektrisiken möchte ich im folgenden, letzten Teil der Blogreihe „Bottleneck Systemverifizierung“ darstellen und mögliche Lösungen aufzeigen.

Mindset Verifizierung

Um die Wichtigkeit der Verifizierung und die einzelnen Testphasen im Rahmen der Entwicklung zu verstehen, muss man zunächst einen Schritt zurück gehen und darüber nachdenken, was man mit der Verifizierung erreichen möchte. Und hier wird deutlich, dass die Verifizierung nicht nur der finale Akt und Pflicht ist, damit man ein Produkt in einen regulierten Markt einbringen darf, sondern die Maßnahme während der Entwicklung ist, um die Qualität des Produkts und die Konformität des Produkts mit externen Standards sicherzustellen. Dies bedeutet automatisch, dass jegliches Kürzen von Testphasen automatisch zu einer Schwächung der Produktqualität führen kann und wird. Werden die Verifizierungsmaßnahmen ausschließlich auf die „formale“ Freigabe des Produkts beschränkt, ist nicht sichergestellt, dass das Produkt auch eine entsprechende Qualität erreicht. Denn hier gilt auch, dass sich die Qualität des Produkts nicht über die Qualität seiner Dokumente für die Freigabe definiert, sondern über die Qualität der Implementierung und Verarbeitung. Und wie lässt sich diese sicherstellen? Natürlich nur durch arbeiten/testen am Gerät und nicht durch oberflächliche Tests und Dokumentation am Arbeitsplatz. Es ist somit notwendig, dass jedem Stakeholder in einem Projekt die Wichtigkeit des „Werkzeuges“ Verifizierung bewusst ist und er dieses auch richtig einsetzt.

Effektiv planen

Jetzt ist natürlich nicht alles Gold, was die Verifizierung tut und auch nicht jede Maßnahme rechtfertigt die Ressourcen und Aufwände, um diese zu erreichen. Dies bedeutet, dass innerhalb eines Projekts ehrlich und effektiv geplant werden muss. Hierbei sollte nie geplant werden nach dem Motto „Das haben wir schon immer so gemacht“. Vielmehr sollte man jede seiner geplanten Maßnahmen nach den folgenden Kriterien hinterfragen:

• Was sind meine Eingangskriterien für die Verifizierungsphase?
• Was ist mein Ziel der Verifizierungsphase?
• Was sind meine messbaren Ergebnisse der Verifizierungsphase?

Da nun die Bewertung der formalen Verifizierung zu simpel wäre, möchte ich die Kriterien anhand der explorativen Testphase gedanklich durchspielen:

Was sind die Eingangskriterien

Wann könnte man mit der explorativen Testphase beginnen? Lässt sich dies an einem festen Zeitraum im Projektplan festlegen? Leider nur indirekt, vielmehr bedingt der Beginn einer explorativen Testphase einen definierten Stand eines Features oder des gesamten Produkts. Somit muss klar sein, welche Funktion mit welchem Stand getestet werden kann. Hält man sich nur an einen Zeitplan, der Monate zuvor definiert wurde, ist die Wahrscheinlichkeit groß, dass man Blindleistung in der Verifizierung erzeugt und diese von anderen Aufgaben abhält, wie zum Beispiel der der Spezifikationen der formalen Tests. Die schnellsten Feedbackschleifen von explorativen Tests erhält man durch den Einsatz von agilen Methoden. Bei diesen Methoden erreicht man am Ende eines Sprints einen definierten Stand den man mit dem folgenden Ziel explorativ testen könnte.

Was sind die Ziele der explorativen Testphase?

Im Gegensatz zu der formalen Verifizierung oder der Probeverifizierung, liegt der Fokus bei der explorativen Testphase auf der reinen Funktionalität und der aktuellen Implementierung. Die Anforderungen sind lediglich eine Informationsquelle. Viel wichtiger ist die Erfahrung des Testers, der Fehler erahnt („Error Guessing“) und Implementierung hinterfragt. Gleichzeitig wird in dieser Phase auch sichergestellt, dass das Produkt hinreichend genau spezifiziert wurde.
In größeren Iterationsschritten bietet es sich sogar an projektübergreifend zu testen. Diese sogenannten Test-Partys beschränken sich nicht nur auf die Mitarbeiter der Verifizierung, sondern ermöglichen allen Projektmitgliedern und Stakeholdern interdisziplinär am Gerät explorativ zu testen. Die Verifizierung ist in diesem Zusammenhang eher Gastgeber und Moderator. Dies „spezielle“ Form der explorativen Tests werde ich zu einem späteren Zeitpunkt ausführlich vorstellen.

Was sind die messbaren Ergebnisse der explorativen Testphase?

Jetzt neigt ein motivierter Tester dazu in einer explorativen Testphase bei der Testdauer ins unendliche zu laufen. Deswegen ist es notwendig, dass es definierte, messbare Ausgangskriterien gibt, die einen zeitlichen Rahmen definieren.
Hierbei haben sich die folgenden Abhängigkeiten bewährt:
Thematischer Rahmen definiert das Feature/Funktion, welches im Rahmen des explorativen Tests betrachtet werden sollen
Zeitlicher Rahmen definiert den zeitlichen Rahmen, welcher für das Feature/Funktion vorgesehen ist
Fehlerfindungsrate Metrik für die Anzahl der gefunden Abweichungen pro Zeit
Bei diesen drei Kriterien sollten gelten, dass solange die Fehlerfindungsrate hoch ist, das explorative Testen fortgesetzt wird, auch wenn der zeitliche Rahmen überschritten wird. Jedoch sollte das explorative Testen abgebrochen werden, wenn der thematische Rahmen verlassen wird. Wenn die Fehlerfindungsrate niedrig ist, sollte das explorativen Testen fortgesetzt werden, bis der zeitliche Rahmen erreicht wurde. Dies verhindert, dass ein Tester eine Funktion nur oberflächlich testet.

Streichung von Verifizierungsphasen

Vorangegangen wurde hoffentlich am Beispiel der explorativen Testphase deutlich, wie wichtig die Verifizierungsphasen innerhalb der Entwicklung sind. Dabei hat jede Phase eine eigene, essentielle Funktion innerhalb der Entwicklung, wodurch auch die Streichung oder Kürzung der Phasen eine direkte Auswirkung auf den Projektzeitplan haben.
Explorative Testphase
Die explorative Testphase ist die Phase, in der die Qualität in das Produkt kommt, weil genau diese im Fokus steht. Es werden frühzeitig Designfehler und Spezifikationslücken festgestellt. Wird diese Phase gestrichen oder auch nur gekürzt, führt dies dazu, dass Designfehler und Spezifikationslücken erst relativ spät gefunden werden. Dabei ist auch nicht sichergestellt, dass diese Fehler überhaupt in der formalen oder Probeverifizierung gefunden werden, weil in dieser Phase diese Art der Fehler nicht im Fokus stehen.
Probeverifizierung
Die Probeverifizierung ist ein essentielles Werkzeug, um sicherzustellen, dass die Testspezifikationen funktionieren und dass das Produkt im Grunde eine formale Verifizierung bestehen kann. Dies bedeutet folglich, dass bei einer Streichung oder Kürzung dieser Phase dazu führt, dass die Testspezifikationen nicht abschließend getestet wurden und auch keine Prognose über das Produkt abgegeben werden kann.
Formale Verifizierung
Das Gute an der formalen Verifizierung ist, dass diese Phase nicht gestrichen werden darf. Jedoch wird häufig darauf gedrängt diese Phase „effektiver“ zu gestalten, indem die Testtiefe für die formale Verifizierung reduziert wird. Hier besteht die Gefahr, dass dadurch Qualität verloren geht, sofern vorangegangene Testphasen reduziert oder gestrichen wurden.

Intelligente Planung von Verifizierungsphase

Aus den vorangegangen Überlegungen ergibt sich, dass durch eine Streichung, Reduzierung aber auch durch eine falsche Planung von Verifizierungsphasen die Qualität des zu Produkts gefährdet wird. Ebenfalls führt eine „so haben wir das immer gemacht“ und „Copy-Paste“-Mentalität dazu, dass die Effektivität und Planung von Testphasen nicht hinterfragt werden. Dies führt ebenfalls zur Gefährdung der Produktqualität und zur vermeintlichen Blindleistung der Verifizierung.
Die Antwort auf diese Probleme ist eine intelligente Planung der Verifizierungsphasen. Intelligent insofern, dass in der Projektplanung die benötigten Ressourcen und ggf. Zeitfenster geplant werden können, aber nicht der genaue Startpunkt der einzelnen Phasen. Die einzelnen Verifizierungsphasen sollten vielmehr auf erreichte Meilensteine folgen und klare Eingangskriterien haben. Wird ein Meilenstein mit einer Verzögerung erreicht, beginnt die entsprechenden Verifizierungsphase entsprechend verzögert, was aber nicht den zeitlichen Rahmen der Verifizierungsphase verändert. Nur so kann sichergestellt werden, dass das Werkzeug „Verifizierung“ effektiv genutzt wird und die Verifizierung der Produktqualität dient und nicht dem Selbstzweck.
[toggle type=”” title=”Über SCOPE Engineering”]SCOPE Engineering ist ein erfahrener Engineering-Partner im sicherheitskritischen und streng normenregulierten Umfeld. Als ganzheitlicher Lösungsgestalter unterstützt das Unternehmen seine Kunden dabei sowohl operativ als auch beratend. Durch seine langjährige Branchenerfahrung in der Entwicklung komplexer Systeme bringt das Unternehmen die notwendige fachliche Expertise mit, um ressourcenoptimierte, individuelle Lösungen zu entwickeln. Einen Schwerpunkt setzt das Unternehmen dabei auf den Bereich Test, Verifikation und Validierung. Sowohl Soft- und Hardwaretests, Unit- und Systemtests als auch das Review von Spezifikationen oder Normenprüfungen fallen in das Leistungsspektrum von SCOPE Engineering.[/toggle]