Risikobasiertes Testen

Die Schulungswoche näherte sich dem Ende und ihnen stand nur noch die obligatorische Feedbackrunde bevor. Eddy, Volker und Claudia aus dem Fachbereich schielten schon leicht nervös in die Ecke mit dem Reisegepäck. Ob sie es noch rechtzeitig zum Zug um 15:00 schafften? Dann bliebe wenigstens noch etwas vom Freitagabend über. Nicht, dass die Schulung so langweilig gewesen wäre. Eddy brannte darauf, sein neues Wissen in dem von ihm betreuten Verfahren einzusetzen. Das Thema „Risikobasiertes Testen“ war ihm zwar schon das eine oder andere Mal begegnet, aber wie das jetzt konkret in seinem Arbeitsumfeld angewandt werden konnte war ihm nicht klar gewesen. Und da war es auch gut, dass mit Claudia jemand aus dem Fachbereich dabei gewesen war, denn die Kollegen dort überließen strukturierte und systematische Testaktivitäten gerne der Softwareentwicklung.

Dabei hatten sie, und das war ein Highlight der Schulung gewesen, gerade eben gelernt, dass diese Technik nur dann sinnvoll eingesetzt werden konnte, wenn verschiedene Blickwinkel und Perspektiven auf einen Untersuchungsgegenstand gerichtet wurden und verschiedene Meinungen aller Experten zusammengetragen wurden. Sie hatten es in der Vergangenheit oft genug erlebt, wenn es darum ging Testobjekte und Funktionen zu priorisieren: Dann erschien den jeweiligen Stakeholdern alles gleich wichtig und es war immer schwierig gewesen etwa Regressionstestsuiten maßzuschneidern oder, der jeweiligen Zeit und Ressourcenlage gemäß, anzupassen.

Zunächst hatten sie in den ersten Stunden des Kurses über den Begriff Testobjekt nachgedacht und an einigen Beispielen aus ihrem Berufsalltag durchgespielt, welche Auswirkungen die Wahl dieser Entität, auf die sich ihre Testaktivitäten bezogen, mit sich brachte. War sie zu feingranular, zog das eine Menge Aufwand durch Messungen nach sich, wählte man zu große Einheiten, wurden die Aussagen oft trivial. Aber diese Diskussion allein machte ihnen deutlich, wie hilfreich ein gemeinsames Verständnis über die Struktur der Anwendung im Hinblick auf die damit verbundenen Aufgaben der Qualitätssicherung war. Im weiteren Verlauf öffnete ihnen die Dozentin die Augen für die Menge und Vielzahl von Datenquellen, die sie im Verlauf der Entwicklung aber auch der Wartung ihrer Software produzierten, ohne sich im darüber im Detail klar zu sein. Plötzlich gewannen sämtliche Artefakte, wie Konzepte und Spezifikationen, Dokumentationen der Anforderungen und Abweichungen, sowie das Fehlermanagement und nicht zuletzt der Quellcode, eine zusätzliche Wertigkeit als Datenquelle, die sie in ihrem Modell für die Risikobetrachtung mit einsetzen konnten.

Außerdem übten sie sich in der Durchführung von Expertenbefragungen und -interviews. In der Vergangenheit waren sie oftmals der Versuchung erlegen aufwändige Fragebögen zu entwerfen, wenn sie bestimmte Fragen an Experten hatten. Der Aufwand, der insbesondere auch bei der Auswertung solcher Fragebögen entstand, war dann regelmäßig unterschätzt worden. Da hatten sich, so die Dozentin, die direkte Ansprache und Befragung, allerdings dann mindestens mit einer stichwortartigen schriftlichen Dokumentation der Antworten, bewährt um schnell Sachverhalte zu klären.

Nachdem diese Grundlagen geklärt waren, lernten sie geeignete Modelle zu entwickeln, in denen sie die unterschiedlichen Daten zusammenführten, um zu einem gemeinsamen Bild über die damit verbundenen Risiken kommen zu können. Sicher, am Anfang war das ein gewisser Aufwand, der zum Stirnrunzeln des einen oder anderen Verantwortlichen führen würde, aber mittel- und langfristig würden sie durch den Einsatz des Risikobasierten Testen die ohnehin immer knappen Ressourcen besser und vor allem intelligenter einsetzen können.