In meinem vorherigen Artikel habe ich beschrieben, dass Testing im Kern Risikomanagement in Reinform ist. Ich stellte dar, wie grundlegende Phasen des Risikomanagements auf Testaktivitäten abgebildet werden. In diesem Beitrag möchte ich das erste Prinzip des Risikomanagements beleuchten – und herausfinden, inwiefern es auch auf das Testing übertragbar ist, und ob wir daraus wertvolle Lehren ziehen können. Könnten Testing und Risikomanagement tatsächlich identisch sein?
Wichtige Eigenschaften der Prinzipien des Risikomanagements, die auch für Testing gelten sollten:
Universell – anwendbar für jede Organisation.
Selbstvalidierend – in der Praxis bewährt.
Stärkend – gibt den Praktizierenden Sicherheit und Klarheit.
Alle vorgeschlagenen Parallelen im Testing müssen diese Kriterien erfüllen: Sie sollten in jedem Projekt anwendbar sein, allgemein akzeptiert sein und klare Orientierung bieten, die auch Stakeholdern vermittelt werden kann.
Prinzip 1: Ausrichtung an den Zielen
Prinzip 1: Risikomanagement orientiert sich kontinuierlich an den Zielen der Organisation.
Die wichtigsten Indikatoren dieses Prinzips sind:
Indikator A
Indikator A: Organisationen müssen ihre Ziele genau verstehen, um eine Balance zwischen Chancen und Risiken zu finden.
Organisationen müssen ihre Ziele genau verstehen, um eine Balance zwischen Chancen und Risiken zu finden.
Chance: Der Nutzen, den die ausgelieferte Anwendung bietet, wenn sie wie beabsichtigt funktioniert.
Risiko: Die Möglichkeit, dass die Anwendung nicht korrekt funktioniert – also Fehler enthält – und den erwarteten Mehrwert nicht liefert.
In Tests findet ein Balanceakt statt zwischen:
Zu viel Testen (ökonomisch unwirtschaftlich)
Zu wenig Testen (Risiko von defekter Software)
Diese Balance zwischen Aufwand und Nutzen sollte bewusst gehalten werden – eine Erkenntnis, die viele Tester teilen. Allerdings findet Stakeholder-Einbindung (z. B. Genehmigung des Testumfangs) hierfür nicht immer ausreichend statt. Agile Teams tun dies häufig besser aufgrund engerer Zusammenarbeit zwischen Testern, Product Ownern und Stakeholdern.
Balance
Das Gefühl für Balance ist im Testing immer vorhanden. Die Balance, um die es dabei geht, liegt zwischen zu viel und zu wenig Testen. Da bei Projekten und Anwendungen fast immer ein finanzielles Ziel eine Rolle spielt, ist Balance hier entscheidend. Wir müssen daher stets darauf achten, nicht mehr Zeit und Geld ins Testen zu investieren, als es letztlich wert ist. Ich bin überzeugt, dass den meisten Testern dies bewusst ist. Das Verhältnis von Kosten zu Nutzen ist sicher ein Punkt, den ich auch im Unterricht immer wieder diskutiere. Deshalb sage ich oft, dass zu viel Testen genauso schlecht ist wie zu wenig – zumindest aus finanzieller Sicht (nicht jedoch, wenn es um sicherheitskritische Systeme geht).
Stellt das Testing sicher, dass die Organisation in diesen Prozess einbezogen wird? Typischerweise geschieht dies dadurch, dass Stakeholder im Rahmen des Testplans gebeten werden, den Umfang des Testens abzunehmen. Später werden Testergebnisse in Berichten an die Stakeholder kommuniziert. Leider ist dieser Prozess nicht immer robust. Stakeholder denken dabei oft nicht aktiv über den Umfang nach – geschweige denn, dass sie ihn aktiv steuern. Häufig schlägt der Testmanager oder das Team den Umfang vor, der dann von den Stakeholdern lediglich passiv abgenickt wird. So kann es vorkommen, dass Stakeholder etwas freigeben, dessen Bedeutung sie kaum verstehen.
Einige Tester, Teams oder Methoden leisten hier einen deutlich besseren Beitrag, indem sie Stakeholder aktiver in die Diskussionen über den Testumfang und dessen Freigabe einbinden. Das geschieht jedoch meist aus Eigeninitiative, weniger aufgrund klar definierter globaler Standards. Agile Teams machen dies naturgemäß besser – vor allem durch die engere Kommunikation mit dem Product Owner und anderen Stakeholdern.
Welche Lehren sind zu ziehen?
Insgesamt bin ich der Meinung, dass sich dieser erste Indikator klar auf das Testing übertragen lässt. Jedes Element ist erkennbar und wird in gewisser Weise auch in den typischen Testunterlagen berücksichtigt. Dennoch könnten die allgemein formulierten Ziele und Prinzipien des Testens hier besser ausfallen. Sie sollten deutlicher machen, wie wichtig es ist, organisatorische Stakeholder aktiv einzubeziehen, und konkrete Hinweise geben, wie dies erreicht werden kann. Außerdem sollten wir klarer betonen, wie notwendig eine Balance zwischen zu viel und zu wenig Testing ist. Das würde Stakeholdern helfen, den Umfang besser zu verstehen und sich aktiv an den Diskussionen dazu zu beteiligen.
(Eine berechtigte Frage wäre jetzt: Bietet das Risikomanagement Praktiken, um diese Ziele zu erreichen? Oder handelt es sich lediglich um hochtrabende Aussagen ohne Substanz? Das ist Thema für einen zukünftigen Artikel – die kurze Antwort lautet: Ja, es bietet konkrete Praktiken.)
Es ist bemerkenswert, dass es sich hierbei erst um Indikator 1 des Prinzips 1 im Risikomanagement handelt – und doch gibt es bereits wichtige Lehren, die wir daraus ziehen können.
Indikator B
Indikator B: Das Ausmaß an Risiko, das eine Organisation bereit ist einzugehen, und das damit verbundene Maß an betriebenem Risikomanagement muss mit den Unternehmenszielen übereinstimmen. Um dies zu erreichen, sollte eine Organisation ihre Risikokapazität und ihre Risikobereitschaft (Risk Appetite) bestimmen.
Lässt sich das auf das Testing übertragen? Absolut – das erste Prinzip im Testing lautet, dass wir niemals beweisen können, dass keine Fehler vorhanden sind. Mit anderen Worten: Wir können das Risiko, dass Defects in die Produktion gelangen, niemals vollständig auf null reduzieren.
Leider ist unseren Stakeholdern dies oft nicht so bewusst wie den Testern selbst. Das liegt zum Teil daran, dass sie nicht konsequent und effektiv in den Prozess eingebunden werden – siehe oben. Dadurch bleibt häufig unklar, was ihre tatsächlichen Bedürfnisse sind. Wir haben oft kein klares Verständnis davon, welches Qualitätsniveau sie benötigen. (Qualität und Qualitätsniveau sind in diesem Zusammenhang unsere Begriffe für das Gegenteil von Risiko und Risikobereitschaft).
Sowohl wir als auch die Stakeholder wissen daher oft nicht genau, wie viel Testing genug ist – nicht zu wenig, aber auch nicht zu viel. Der Umfang der Tests und die Abnahme durch Stakeholder mittels Sign-off sind die Mittel, mit denen wir dies adressieren. Aufgrund der bereits angesprochenen Schwächen handelt es sich dabei jedoch häufig um eine schlecht verstandene und unzureichend quantifizierte Vereinbarung.
Ich bin der Meinung, dass die bestehenden, allgemein formulierten Testpraktiken hier keine gute Arbeit leisten. Sie sollten die Notwendigkeit klar herausstellen, dass die Organisation ihre Qualitätsanforderungen und Risikotoleranz eindeutig definiert. Genau an diesem Punkt knüpfen die in Indikator A beschriebenen Schwierigkeiten erneut an.
Indikator C
Indikator C: Ein zentraler Aspekt erfolgreichen Risikomanagements ist das gemeinsame Verständnis zwischen Stakeholdern, dass Risiko dynamisch und nicht statisch ist. Risikomanagement muss daher ein wiederholender Prozess sein, der Veränderungen antizipiert und darauf reagiert.
Lässt sich das auf das Testing übertragen? Wieder ja. Wir Tester wissen sehr genau, dass sich während des Testens und bei Änderungen an der Anwendung neue Risiken ergeben, die zusätzliche Tests erforderlich machen.
Tun wir jedoch genug, um unseren Stakeholdern dieses dynamische Risikobild zu vermitteln? Eher nicht. In den gängigen Testpraktiken gibt es keinen automatischen Prozess, um den Testumfang regelmäßig neu zu präsentieren und eine erneute Genehmigung der Stakeholder einzuholen.
Oft besprechen wir notwendige Änderungen mit dem Projektmanager (oder im agilen Kontext direkt im Team), und das mag im Einzelfall ausreichen – doch ein klarer, standardisierter Prozess oder ein fest verankertes Prinzip fehlt. Wiederum gelingt es einzelnen Teams oder Methoden deutlich besser, diese Dynamik zu berücksichtigen und aktiv zu kommunizieren.
Fazit: Risiko und Testing
Zusammenfassung – Das erste Prinzip des Risikomanagements lässt sich klar auf das Testing übertragen und unterstützt damit die Argumentation, dass Testing und Risikomanagement eng miteinander verbunden sind. Gleichzeitig wird jedoch deutlich, dass unsere allgemein verbreiteten Materialien Schwächen darin aufweisen, wie Stakeholder effektiv einbezogen werden – zum Nachteil sowohl für sie selbst als auch für die Testteams.
Ausblick: Beim nächsten Mal betrachten wir Prinzip 2.
Joe Elledge ist ein akkreditierter Trainer für BCS, ICAgile, iSQI, PeopleCert und ISTQB-Kurse und verfügt über mehr als 20 Jahre Erfahrung in den Bereichen Testmanagement, Qualitätssicherung und Training. Er hat in einer Vielzahl von Branchen gearbeitet, darunter Telekommunikation, Banken, Versicherungen und Automobilindustrie, sowie in unterschiedlichen Regionen wie Großbritannien, Irland, Deutschland, Indien, den USA, Skandinavien und der Schweiz.
Erfahren Sie mehr über uns und unsere anderen Trainer der Expleo Academy.
