Lassen Sie uns über das risikobasierte Testen sprechen. Ich sollte wahrscheinlich zuallererst erwähnen, dass dies ein heikles Thema ist. Darum ist eine Karriere als Qualitätsexperte auch nichts für Menschen mit schwachen Nerven. Fakt ist, dass Kosten, Qualität und Auslieferung in jeder Branche – auch Software – zueinander in Konkurrenz stehen. Bei diesem Drahtseilakt spielen Qualitätsexperten eine wesentliche Rolle. Und wenn die Balance zu kippen droht, sind häufig wir Qualitätsexperten die Missetäter – oder fühlen uns wenigstens so.
Lange habe ich mich selbst bemitleidet. Warum konnte niemand verstehen, wie schwer meine Aufgabe war? Jeden Tag der schwere Kampf gegen die, die Qualität zugunsten von Kosten und/oder Auslieferung opfern würden, Aufstehen für die Wahrheit und Gerechtigkeit und ... na gut, es gab keine Bösewichte, ich bin kein Superheld, und ganz so dramatisch war es dann doch nicht. Doch es ist eine Herausforderung, die perfekte Balance zwischen Qualität und Auslieferung zu halten!
Im Laufe der Jahre ist es jedoch offensichtlich geworden, dass es keine Korrelation zwischen der für die Tests aufgewendeten Zeit und der Qualität der ausgelieferten Produkte gibt. Das ist eine doch Erleichterung, oder? Na ja, nicht wirklich. Es bedeutet nicht, dass die Qualitätssicherung einfacher ist, sondern nur, dass „mehr vom Gleichen“ nicht die Lösung ist. Es ist viel komplexer.
Ich habe gelernt, dass die Qualitätssicherung nicht davon ausgemacht wird, wie viel wir testen, sondern davon, wie wir dies tun. Ehrlich gesagt geht es häufig sogar überhaupt nicht um das Testen (mehr dazu in einem künftigen Artikel).
Wie balancieren wir also Kosten, Qualität und Auslieferung bei Minitab aus? Sehr vorsichtig. I würde gerne sagen, dass wir es jedes Mal perfekt schaffen, aber dann würde ich nicht die Wahrheit erzählen – und als Qualitätsexperte muss ich rigoros auf Ehrlichkeit bestehen. Und um es zu wiederholen: Eine Stelle als Experte für Qualitätsverbesserung ist nichts für Menschen mit schwachen Nerven! Ich kann jedoch bekräftigen, dass Minitab die Qualität sehr ernst nimmt und jeder, der hier arbeitet, seinen Beitrag dazu leistet, die Qualität kontinuierlich zu verbessern.
Dieses Thema reicht für viele Artikel aus, aber wir beginnen mit dem risikobasierten Testen (RBT). Da es für jede Funktion oder Version eine nahezu unendliche Anzahl von Testfällen gibt, verbietet es sich aus Kosten- und Zeitgründen, jeden möglichen Test durchzuführen. Die Funktion eines Qualitätsexperten besteht darin, festzulegen, welche Tests wie oft und auf welche Weise durchgeführt werden sollen. Ich vergleiche dies gerne mit meiner Zeit in der Fertigung, als wir Stichprobenpläne für die Inspektion nutzten. Wir konnten nicht alles untersuchen, aber wir konnten auf sehr intelligente Weise festlegen, was wir untersuchen sollten.
Bei Minitab nutzen wir RBT, um Teststrategien zu entwickeln, die auf dem Fehlerrisiko basieren. Hierbei handelt es sich um eine Funktion der Auftretenswahrscheinlichkeit und des Schweregrads. Zur Unterstützung nutzen wir die Fehlermöglichkeits- und -einflussanalyse (FMEA) in Minitab Engage.
Ich habe das erste Mal eine FMEA genutzt, als ich in den frühen 90er-Jahren in der Medizintechnik arbeitete. Sie hat schon damals gut funktioniert und ist immer noch – fast 20 Jahre später – eines meiner Lieblingswerkzeuge. Engage hat sie natürlich viel benutzerfreundlicher gemacht, als sie vor 20 Jahren war! Wie unten veranschaulicht wird die FMEA verwendet, Fehler basierend darauf zu priorisieren, wie schwer sie sind, wie häufig sie auftreten und wie einfach sie zu erkennen sind. Auf der Grundlage dieser Auswertung können klare Strategien für die Risikominimierung aufgestellt und umgesetzt werden.
Auszug aus einer vom Minitab-Team konzipierten PFMEA (Produktfehlermöglichkeits- und -einflussanalyse):
1) Geben Sie im Feld Prozessabbildung-Aktivität (Process Map Activity) jeden Prozessschritt, jedes Merkmal bzw. jede Funktion oder jede Art von Aktivität ein. Im oben gezeigten Beispiel handelt es sich um das Testen von Dialogfeldern auf Funktionsebene
2) Geben Sie im Feld Potenzieller Fehlermodus (Potential Failure Mode) für jede Aktivität die möglichen Fehler ein. Es kann mehrere Fehlermöglichkeiten geben. Im oben gezeigten Beispiel gibt es keine Testskripts zum Validieren der Funktion jeder Tastenkombination in jedem Dialogfeld
3) Geben Sie im Feld Mögliche Auswirkungen von Fehlern (Potential Failure Effects) für jede Fehlermöglichkeit die potenziellen Auswirkungen eines Fehlers ein. Für jede Fehlermöglichkeit kann es mehrere Auswirkungen geben. Der potenzielle Fehler oben ist folgender: Wenn ein Entwickler eine Änderung vornimmt (nach der Verifizierung des Dialogfelds) und durch diese Änderung eine Tastenkombination funktionslos wird, wird dieser Fehler möglicherweise nicht erkannt.
4) Geben Sie im Feld SEV (Schweregrad oder Severity Rating) eine Schätzung für den Schweregrad für jede Fehlerauswirkung ein. Nutzen Sie eine Skala von 1 bis 10, wobei 10 einen hohen und 1 einen niedrigen Schweregrad darstellt. Dieser Wert ist relativ. In unserer Welt haben die Tastenkombinationen einen geringeren Schweregrad als beispielsweise die statistischen oder grafischen Ergebnisse. Wir haben diesem Problem einen Schweregrad von 3 zugeordnet.
5) Geben Sie im Feld OCC (Auftretenswahrscheinlichkeit oder Occurrence Rating) eine Schätzung für die Wahrscheinlichkeit ein, mit der das Problem auftritt. Verwenden Sie eine Skala von 1 bis 10, wobei 10 eine hohe Häufigkeit (tritt sicher laufend auf) und 1 eine geringe Häufigkeit (tritt sehr unwahrscheinlich auf) darstellt. In unserem Beispiel ist die Wahrscheinlichkeit, eine Tastenkombination nachträglich zu ändern, niedrig, aber es ist nicht unmöglich. Wir haben die Auftretenswahrscheinlichkeit mit 2 bewertet.
6) Geben Sie im Feld Aktuelle Kontrollen (Current Controls) ein, wie die Fehlerursachen/-möglichkeiten erkannt oder kontrolliert werden. Beim Testen von Dialogfeldern validieren wir jede Tastenkombination manuell, automatisieren die allgemeine Validierung von Tastenkombinationen und führen Schnelltests durch
7) Geben Sie im Feld DET (Bewertung der Erkennung oder Detection rating) ein, wie gut jeder Kontrollmechanismus die entsprechende Fehlerursache/-möglichkeit erkennen oder kontrollieren kann. Verwenden Sie eine Skala von 1 bis 10. Hierbei ist 10 eine schlechte Erkennung/Kontrolle (der Kunde erhält fast sicher eine mangelhafte Ausgabe) und 1 eine gute Erkennung/Kontrolle (fast sichere Erkennung; allgemein wird die Ursache gefunden, bevor sie tatsächlich zu einem Fehler führen kann). In unserem Beispiel ist die Wahrscheinlichkeit, das Problem zu erkennen, nicht hoch. Doch aufgrund der allgemein durchgeführten manuellen Tests ist es durchaus möglich, dass wir es erkennen. Wir haben als Erkennungswahrscheinlichkeit 5 festgelegt.
8) Prioritätsnummer des Risikos (RPN oder RPZ) auswerten: Der Eintrag unter RPN ist das Produkt aus den Werten für SEV, OCC und DET. Die RPZ ist die Gesamtbewertung für eine Kombination aus Möglichkeit, Auswirkung und Ursache. Je höher die RPZ, desto schwerwiegender, häufiger oder weniger kontrolliert ist das potenzielle Problem und desto dringender muss diesem die unmittelbare Aufmerksamkeit zukommen. In unserem Beispiel war die RPZ 30, und deshalb entschieden wir uns, die Situation auszuwerten und zu bestimmen, ob sich irgendetwas automatisieren ließe. Unser Testarchitekt fand eine andere Lösung, mit der unsere Erkennungswahrscheinlichkeit gesteigert wurde
9) Nachdem Korrekturmaßnahmen ergriffen wurden, geben Sie die neuen Werte für SEV, OCC und DET ein, um eine neue PRZ zu berechnen. In unserem Beispiel wurde die RPZ auf einen äußerst akzeptablen Wert von 6 reduziert!
Das FMEA-Werkzeug in Engage eignet sich ausgezeichnet, um unsere risikobasierten Auswertungen und resultierenden Teststrategien zu analysieren, zu verwalten und zu kommunizieren. Im Beispiel oben wurde ein automatisiertes System erarbeitet, um die QA auf Änderungen der Dateien aufmerksam zu machen. Dies war eine kosteneffektive Strategie zur Risikominimierung für das vorliegende Problem. Die FMEA bot eine Struktur, die die Teams durch die Analyse führte und dann die Logik hinter der Entscheidung dokumentierte.
Die FMEA wird außerdem vorgehalten und dient als Aufzeichnung für diese Art von Entscheidungen. Ich muss keinem Qualitätsexperten erzählen, wie nützlich das ist, um künftige Diskussionen um die Frage „Warum genau haben wir uns entschieden, so zu verfahren?“ zu vermeiden. Ich wünschte nur, dass es Engage bereits gegeben hätte, als ich vor 20 Jahren begann, mit FMEAs zu arbeiten!