Da Softwarefehler erhebliche Auswirkungen auf Ihren Geschäftsbetrieb haben können, ist es unerlässlich, Änderungen und IT-Projekte ordnungsgemäß zu testen. In Anbetracht der begrenzten Zeit und des begrenzten Geldes, die für Tests zur Verfügung stehen, müssen bestimmte Entscheidungen getroffen werden. Da es beim Testen nicht um das Auffinden von Fehlern, sondern vor allem um die Abdeckung von Risiken geht, werden diese Entscheidungen am besten auf der Grundlage einer Produkt-Risiko-Analyse (PRA).
Durch die PRA wird jedem System oder jeder Prozesskomponente (den "Produkten") ein Risikokennzeichen zugewiesen. Für jede Risikokennzeichnung wird dann ein individueller Prüfansatz festgelegt. Dadurch wird der Druck auf den kritischen Pfad begrenzt und die risikoreichsten Teile werden zuerst und am gründlichsten getestet.
Projektrisiko oder Produktrisiko?
Während eines Projekts werden die Begriffe Projektrisiken und Produktrisiken fälschlicherweise synonym verwendet, obwohl es sich um zwei völlig unterschiedliche Dinge handelt. Wenn sich Risiken auf das gesamte Projekt beziehen (z. B. "unzureichende Ressourcen für Tests aufgrund der Urlaubszeit"), handelt es sich um Projektrisiken. Von Produktrisiken spricht man nur, wenn sich die Risiken direkt auf die verschiedenen zu realisierenden System- oder Prozesskomponenten (Produkte) beziehen.
Da selbst ein kleines Projekt eine große Anzahl von Produkten umfassen kann, ist es wichtig, einen Überblick über die Produkte zu behalten. Die Erstellung einer Baumstruktur mit allen Produkten ist eine praktische Möglichkeit, die Produkte darzustellen. Diese Baumstruktur dient dann als Ausgangspunkt für die PRA.
Eine beispielhafte Baumstruktur sieht in Testersuite wie folgt aus:
Fehlerwahrscheinlichkeit mal Schaden".
Die Wahrscheinlichkeit, dass ein Produkt nicht richtig funktioniert, wird als Fehlerwahrscheinlichkeit bezeichnet. Die Fehlerwahrscheinlichkeit ist höher, wenn ein Produkt größtenteils aus maßgeschneiderter Software besteht, wenn das Produkt viel genutzt wird oder wenn der unterstützte Prozess sehr komplex ist. Da die Beteiligten aus der IT den meisten Einblick in diese Aspekte haben, liefern sie idealerweise den Input zur Fehlerwahrscheinlichkeit. Auch hier ist es wichtig, die Argumentation abzusichern.
Als Schaden bezeichnen wir den Umfang und die Schwere der (potenziellen!) Probleme, die durch ein fehlerhaftes Produkt verursacht werden. Beispiele für Schäden sind Imageschäden, Umsatzeinbußen oder hohe Reparaturkosten. Kunden aus dem Unternehmen oder andere Interessengruppen aus dem Unternehmen bestimmen den (geschäftlichen) Schaden pro Produkt. Auch hier ist es wertvoll, diese Argumentation festzuhalten.
Als Ergebnis werden auf Produktebene die Klassifizierung für die Fehlerwahrscheinlichkeit, deren Erklärung, die Klassifizierung für den Schaden einschließlich Erklärung und das Endrisiko definiert:
Offensichtlich müssen beide Aspekte berücksichtigt werden, um das endgültige Risiko zu bestimmen. Nach der Theorie von TMap bestimmt "Fehlerwahrscheinlichkeit mal Schaden" die Risikoklassifizierung, in der Praxis funktioniert jedoch eine einfache Tabelle besser als ein mathematischer Ansatz zur Risikobestimmung:
Der Schaden wiegt offensichtlich schwerer als die Fehlerwahrscheinlichkeit. Wenn der Schaden gering ist, ist die Wahrscheinlichkeit dieses begrenzten Schadens weniger relevant. Es ist ratsam, die Klassifizierung der Risiken begrenzt zu halten (wie im obigen Beispiel Niedrig/Mittel/Hoch), da für jede Risikoklasse ein anderer Prüfansatz verwendet werden sollte.
Am effektivsten lässt sich die PRA in Form eines Workshops mit allen Beteiligten aus IT und Wirtschaft durchführen. Um zu lange Diskussionen zu vermeiden, ist es ratsam, die PRA-Sitzung von einem unabhängigen Moderator des Prozesses leiten zu lassen. Testersuite hat viel Erfahrung in der Leitung solcher Sitzungen.
Risikobasierter Prüfansatz
Die Risikoklassen dienen als Leitfaden für die Planung der Testspezifikation und -durchführung. Idealerweise sollte auch die Entwicklungsarbeit auf der Grundlage der gleichen Risiken geplant werden, wobei die Produkte mit dem höchsten Risiko zuerst entwickelt werden. In Projekten werden unter Zeit- und/oder Gelddruck oft Kompromisse bei der Testarbeit gemacht. Um die Wahrscheinlichkeit zu erhöhen, dass die Qualität von Produkten mit hohem Risiko nicht beeinträchtigt wird, ist es vorzuziehen, auf der Grundlage von Risiken zu planen und zu arbeiten. Die Risikoklassen können auch verwendet werden, um Prioritäten bei der Fehlerbehebung, der Dokumentation oder bei Vereinbarungen mit externen Lieferanten zu setzen. Außerdem trägt eine PRA-Sitzung zur Sensibilisierung für das Testen bei.
Indem man den Testansatz auf Produktrisiken stützt, wird es möglich, die verfügbaren Testressourcen für die wichtigsten Fragen zu verwenden. Eine PRA ist auch in hohem Maße für künftige Testprojekte wiederverwendbar, da sich insbesondere bestimmte Schäden nicht schnell ändern. Hier ist es wichtig, die Ergebnisse einer PRA ordnungsgemäß zu erfassen. Testersuite bietet umfassende Unterstützung für Risikotests und erleichtert auch die Wiederverwendung von Risikoklassen.
