Jeder Testingenieur, Verifizierungsingenieur oder Tester kennt es: Zum Ende des Projekts liefert die Entwicklung einen vermeintlich finalen Stand eines Produkts ab, oft bereits mit einer Verzögerung. Nun nimmt der Druck auf die Verifizierung zu, die abschließenden Tests für die Freigabe durchzuführen. Oft wird in dieser Phase die Frage aus der Entwicklung gestellt, was am Testen so lange dauert. Schließlich sei doch die Entwicklung bereits abgeschlossen und das Produkt bereit für den Markt.
In diesem Zusammenhang wird die Verifizierung häufig als Bottleneck der Entwicklung bezeichnet. Dies stellt die Gegebenheiten innerhalb einer Produktentwicklung zu einfach dar. Natürlich befindet sich die Systemverifizierung als abschließender Nachweis für die Erfüllung der Anforderungen am Ende der Entwicklung in einer herausgestellten Position. Die lange Phase der Entwicklung ist abgeschlossen, das Produkt macht (hoffentlich) einen serienreifen Eindruck und es müssen jetzt “nur noch” die formalen Tests durchgeführt und bestanden werden. Doch häufig wird aus dem “nur noch” schnell eine weitere Entwicklungsschleife, werden Anpassungen an den Anforderungen und am Produkt notwendig. Es entsteht schnell der Eindruck, dass sich die Verifizierung mit Händen und Füßen gegen eine Freigabe wehren würde. Wodurch entsteht dieser Eindruck?
So vielseitig die Facetten der Produktentwicklung sind, so vielfältig sind auch die Gründe für die Verzögerung während der Verifizierung. Einige Gründe finden sich aber in fast allen Projekten wieder:
1) Risiko durch eine späte Einbindung der Verifizierung
In fast allen Projekten wird die Verifizierung erst spät in die Entwicklung eingebunden. Dies kann zum einen seine Ursache in knappen Ressourcen haben, die in anderen Projekten benötigt werden oder dem Projektleiter ist nicht bewusst, dass die rechtzeitige Einbindung notwendig ist. Dabei ist eine Einbindung der Verifizierung bereits in die Phase der Anforderungsdefinition mehr als sinnvoll. Hierdurch kann bereits früh sichergestellt werden, dass die Anforderungen testbar sind, dass die Funktionen vollständig spezifiziert sind und normative Anforderungen berücksichtig werden. Darüber hinaus werden die notwendigen Maßnahmen für die Verifizierung frühzeitig erkannt, definiert und geplant. Dadurch wird die gesamte Planung effektiver und zuverlässiger.
2) Späte Änderungen an den Produktanforderungen
Ein weiteres Problem für die Verifizierung sind späte Änderungen am Produkt und den damit verbundenen Anpassungen in den Anforderungsdokumenten. Änderungen in den Anforderungsdokumenten machen in den meisten Fällen eine Anpassung der Testspezifikationen, sowie der Verifizierungsdokumente notwendig, wodurch die Verifizierung unter Zeitdruck gerät, die eigenen Dokumente abzuschließen.
Häufig fehlen in den Projekten das Verständnis und die Weitsicht, welche Folgen späte Änderungen der Anforderungen haben. Ebenfalls fehlt häufig eine verlässliche und realistische
Planung, die den Zeitbedarf der Verifizierung nach dem Abschluss der Anforderungsdokumente zutreffend abbildet.
Insgesamt gilt die Erkenntnis, dass die Qualität der Tests im Wesentlichen von der Qualität der Anforderungsdokumente abhängt.
3) Fehlende Metriken in der Systemverifizierung
Die Verwendung von Metriken in der Verifizierung, quasi das Darstellen von Fortschritt und offenen Aufwänden wird von einigen Kollegen in der Verifizierung, häufig den älteren, als störend und nicht notwendig empfunden. Es hat sich jedoch gezeigt, dass Verzögerungen bei der Verifizierung, aber auch die Qualität des Entwicklungsstandes des Produktes falsch eingeschätzt werden. Dies ist in den meisten Fällen auf fehlende Metriken zurückzuführen. Durch die Auswahl von geeigneten Metriken wird es den projektbeteiligten Personen ermöglicht, rechtzeitig Abweichung von der Planung zu erkennen und darauf zu reagieren. Erst durch die Auswahl von geeigneten Metriken wird der Erfolg oder Misserfolg sowie der Fortschritt messbar. Diese liefern fundierte Daten für die Steuerung und Bewertung von Projekten.
4) Risiko durch eine falsche Planung von Verifizierungsphasen
Aufgrund von Personalmangel, Zeitmangel oder fehlender Einplanung werden Testphasen wie eine explorative Testphase oder eine Probedurchführung der Testspezifikation gestrichen. Durch die Streichung wird das Projektrisiko auf die offizielle Testphase verschoben. Dadurch ist es unwahrscheinlich, dass die ursprünglich geplante Testdauer eingehalten werden kann. Das Risiko, dass Abweichungen mit einer hohen Kritikalität in der offiziellen Systemverifizierung gefunden werden steigt proportional zu den gestrichenen, entwicklungsbegleitenden Testphasen. Genauso wirkt sich eine schlechte Planung der Verifizierungsphasen auf das Projektrisiko und die Produktqualität aus. Die jeweiligen Verifizierungsphasen sollten jeweils mit „harten“ Eingangskriterien geplant werden. Denn nur wenn man zum richtigen Zeitpunkt mit einem definierten Entwicklungsstand die entsprechende Verifizierungsphase (exploratives Testen, Probeverifizierung etc.) durchführt, hat diese Maßnahme einen Mehrwert für das Projekt und läuft nicht Gefahr Blindleistung zu erzeugen.
Folgen
Als Folge der aufgezeigten Aspekte kommt es häufig zu Aktionismus im Verlauf der Verifizierung:
• weitere Ressourcen werden bereitgestellt (evtl. fehlen diese dadurch bereits in anderen Projekten),
• weitere finanzielle Ressourcen werden zur Verfügung gestellt, die zuvor mühsam eingespart wurden
• Anforderungen werden verändert
• Funktionen werden gestrichen bzw. verschoben
Es wird deutlich, dass durch die Optimierung der oben genannten Aspekte innerhalb eines Projekts die Verifizierung effizienter und mit weniger Ressourcen arbeiten kann. Für die
Entwicklung muss klar sein, dass die Verifizierung Teil der Entwicklung ist und die Qualität des Produkts sicherstellt. Aus diesem Grund ist es notwendig, dass die entsprechenden Ressourcen, Phasen und Voraussetzungen eingeplant und zur Verfügung gestellt werden.
[toggle type=”” title=”Autor: Sebastian Gerlich (Verification-Engineer.de)”]Sebastian Gerlich ist als Testmanagement-Experte mit viel Fingerspitzengefühl in Verifikations- und Validierungsfragen in stark regulierten Branchen unterwegs. Als Shared Testing-Partner von SCOPE Engineering bringt er seine Expertise in die Lösung individueller Testing-Bedarfe ein. Als Freiberufler und in Festanstellung hat Herr Gerlich namhafte Medizintechnik-Unternehmen im Bereich der Produktqualifikation und Verifizierung unterstützt. Seine Schwerpunkte liegen dabei im Systemtest sowie im Testmanagement.[/toggle]