Das QA Navigation Board versetzt Teams in die Lage, für jedes Softwareprojekt zielführend und effizient über die Aspekte der Qualitätssicherung, deren Priorität und Ausprägung in der Durchführung zu entscheiden. Zur Erläuterung seiner Funktionsweise haben wir ein kurzes Video-Tutorial erstellt.
Abbildung 1: QA Navigation Board bei der praktischen Anwendung
Funktionsweise des QA Navigation Board
Jedes Softwareprojekt zeichnet sich durch individuelle Schwerpunkte aus. Daraus ergeben sich in der Folge ebenso spezielle Qualitätsanforderungen. Für die Prüfung dieser Qualitätsanforderungen müssen daher – je nach Themenstellung – die passenden Maßnahmen festgelegt werden. Um hier nicht zu vergessen, die Methoden richtig zu gewichten und die Abfolgen sinnvoll zu planen, haben wir das QA Navigation Board entwickelt: Ein Hilfsmittel, das es Teams ermöglicht, das Testen von Softwareprojekten optimal zu organisieren. Es berücksichtigt die Fragen: Was ist zu testen, wie, in welchem Umfang, wo und wann.
Video-Tutorial
Damit die Nutzung des Boards auf Anhieb gelingt, ist eine Einführung in das Tool hilfreich. In einem ergänzenden Video-Tutorial erklären wir deshalb dessen Funktionsweise. Wie ist es aufgebaut? Welche Schritte der Testplanung erfolgen idealerweise nacheinander und warum? So gelingt der Start Schritt für Schritt bestmöglich.
Erfahrungen mit dem QA Navigation Board
Das QA Navigation Board wird bereits in zahlreichen Projekten konsequent und mit großem Erfolg eingesetzt. Teams, die mit dem Board arbeiten, bestätigen: Es nimmt alle Teammitglieder und ihre jeweiligen Kompetenzen mit. Es sorgt dafür, dass kein Aspekt der Software vergessen und richtig, dem Zweck entsprechend, gezielt qualitätsgesichert wird. Das Arbeiten mit dem QA Navigation Board sorgt so für Übersichtlichkeit, gibt eine klare Orientierung und wird gemeinsam vom gesamten Team in einem Workshop erstellt.
Einführungsworkshop
Für Teams, die das Board in ihre Prozesse einbinden wollen, gibt es selbstverständlich nach wie vor unseren detaillierten Ablaufplan für einen Workshop zur Einführung des QA Navigation Boards. Wie es im Detail ausgefüllt wird und was sich hinter den einzelnen Punkten verbirgt, lässt sich darüber hinaus jederzeit hier nachlesen und immer wieder zur Hand nehmen.
Geht es um das Erkennen typischer QA-Problemfälle, deren Auswirkungen und Beseitigung, dient das Board als Werkzeug für die „Anamnese der QA-Strategie für agile Teams“ – Ein Vorgehensbeschreibung ist hier zu finden.
Mit Hilfe unseres agilen Visualisierungswerkzeugs, dem QA Navigation Board, möchten wir eine Methode vorstellen, mit der agile Entwicklungsteams typische QA-Problemfälle und deren Auswirkungen erkennen und diese beseitigen können.
Vergleichbar mit einem falschen Architekturansatz oder der Verwendung der falschen Programmiersprache kann eine falsche Test- und Qualitätssicherungsstrategie im Laufe des Projektes zu Beeinträchtigungen führen. Im besten Fall kommt es nur zu Verzögerungen oder Mehraufwand. Im schlechtesten Fall wird unzureichend getestet und es tauchen immer wieder schwerwiegende Abweichungen im Betrieb der Anwendung auf.
Einführung
Die Probleme werden durch die agilen Entwicklungsteams bemerkt und die Auswirkungen in der Retrospektive dokumentiert, aber oft können sie wegen fehlender QA-Expertise nicht die Ursache erkennen und somit das Problem auch nicht beheben. Das Team benötigt in diesen Fällen Unterstützung durch einen agilen QA-Coach. Dieser zeichnet sich dabei zum einen durch seine Kenntnisse in der agilen Arbeitsweise aus, aber zum anderen auch durch seine Erfahrungen in der agilen Qualitätssicherung.
Der erste Schritt in der Arbeit des agilen QA-Coaches ist es, den aktuellen Stand des Testvorgehens des agilen Entwicklungsteams festzuhalten. Dazu nutzt er zum Beispiel in einem Workshop das sogenannte QA Navigation Board. Mit dem QA Navigation Board haben die Entwicklungsteams ein visuelles Hilfsmittel, mit dem sie die planerischen Aspekte der Qualitätssicherung beurteilen können. Dabei kann das QA Navigation Board innerhalb der Projektlaufzeit auch als Referenz des aktuellen Vorgehens und als Ansatz für potenzielle Verbesserung genutzt werden.
Anti-Pattern
Darüber hinaus ermöglicht das QA Navigation Board eine Anamnese des aktuellen Testvorgehens. Der agile QA-Coach kann durch die Visualisierung bestimmte Symptome für Anti-Pattern im Qualitätssicherungs- und Testprozess aufdecken und diese mit dem Team direkt besprechen. Als Anti-Pattern werden in der Softwareentwicklung Lösungsansätze bezeichnet, die ungünstig oder schädlich für den Erfolg eines Projektes oder einer Organisation sind.
Nachfolgend möchte ich verschiedene Anti-Pattern vorstellen. Neben den Eigenschaften zur Identifikation, stelle ich noch deren Auswirkungen dar. Im Sinne des Gegenstücks zum Anti-Pattern, dem Pattern, werden auch gute und bewährte Problemlösungsansätze vorgestellt.
Anti-Pattern – Wird schon gut gehen
Dieses Anti-Pattern zeichnet sich durch das komplette Fehlen von Tests oder anderen Maßnahmen zur Qualitätssicherung aus. Dadurch ergeben sich schwerwiegende Konsequenzen für das Projekt und das Produkt. Das Team kann keine Qualitätsaussage über das Ergebnis seiner Arbeit treffen und besitzt damit streng genommen kein auslieferungsfähiges Produkt. Die Fehler tauchen beim Endanwender auf und sorgen damit immer wieder für Ablenkung im Entwicklungsprozess des Teams, da die sogenannten Incidents aufwendig analysiert und behoben werden müssen.
Keine Tests
Auswirkungen
Lösung
• Es gibt keine Tests
• Keine Qualitätssausage
• „Schnell weggehen“
• Getestet wird beim Anwender
• QA einführen
Der Lösungsansatz ist einfach: Testen! Je eher Abweichungen gefunden werden, desto einfacher lassen sie sich beseitigen. Darüber hinaus sorgen Qualitätssicherungsmaßnahmen wie Codereviews und statische Codeanalyse als konstruktive Maßnahmen für eine Verbesserung.
Anti-Pattern – Dysfunktionaler Test
Laut ISO 25010 gibt es acht verschiedene Qualitätskriterien für Software: Funktionalität, Effizienz, Kompatibilität, Benutzbarkeit, Zuverlässigkeit, Sicherheit, Wartbarkeit und Übertragbarkeit. Meist liegt der Schwerpunkt bei der Umsetzung neuer Software auf der Funktionalität, aber heutzutage spielen anderen Kriterien wie Sicherheit und Benutzbarkeit eine wichtige Rolle. Je höher die Priorität der anderen Qualitätskriterien ist, desto wahrscheinlicher ist es, für diese einen nicht-funktionalen Test vorzusehen.
Darum sollte die erste Frage zu Beginn eines Softwareprojektes lauten, auf welchen Qualitätskriterien der Fokus der Entwicklung und damit auch der Qualitätssicherung liegt. Um den Teams einen einfachen Einstieg in das Thema zu geben, nutzen wir den QA-Oktanten. Folgend der ISO 25010 beinhaltet der QA-Oktant die Qualitätskriterien für Softwaresysteme. Sie geben aber auch einen Hinweis auf die notwendigen Testarten, welche sich aus der gesetzten Gewichtung der unterschiedlichen funktionalen und nichtfunktionalen Kriterien ergeben.
Nur funktionale Tests
Auswirkungen
Lösung
• Es gibt nur funktionale Tests
• Keine Qualitätssausage über nicht-funktionale Kriterien
• Wichtige Qualitätskriterien mit Kunden besprechen
• Es geht wie gewollt, aber …
• Nicht-funktionale Testarten
• Mit dem QA-Oktanten starten
Anti-Pattern – Angriff der Dev-Krieger
Viele agile Entwicklungsteams – besonders Teams, die nur aus Entwicklern bestehen – setzen bei ihren QA-Maßnahmen nur auf entwicklungsnahe Tests. Meist kommen hier nur Unit- und Komponententests zum Einsatz. Diese lassen sich einfach im gleichen Entwicklungswerkzeug schreiben und schnell in den Entwicklungsprozess integrieren. Besonders komfortabel ist dabei die Möglichkeit, dass sich über Code Coverage Tools eine Aussage über die Abdeckung der Tests gegenüber dem Code geben lässt. Schnell tritt nämlich eine Sicherheit ein, wenn das Code Coverage Tool eine 100%-ige Testabdeckung meldet. Doch die Problematik steckt im Detail bzw. hier in der Komplexität. Für einfache Anwendungen wäre dieses Vorgehen ausreichend, aber bei komplexen Anwendungen treten Probleme auf.
Bei komplexen Anwendungen können trotz einer komfortablen Unit-Test-Abdeckung Fehler auftauchen, die sich erst durch aufwendige System- und End2End-Tests entdecken lassen. Und für diese aufwendigen Tests ist es notwendig, ein erweitertes QA-Know-how im Team zu haben. Tester oder geschulte Entwickler müssen auf höheren Teststufen der Komplexität der Anwendung entgegentreten, um hier eine passende Qualitätsaussage zu treffen.
Angriff der DevOnly
Auswirkung
Lösung
• Nur entwicklungsnahe Tests
• Kein End2End-Test
• Tester ins Team holen
• Kein Tester im Team
• Bugs treten bei komplexen Features auf
• Auf höheren Teststufen testen
• 100% Codeabdeckung
• Schnell
Anti-Pattern – Die Spanische Variante
Die Zeit, in der eine Funktion in den Code gebracht wurde und dann auf dem Zielsystem landet, wird immer kürzer. Damit verkürzt sich auch die Zeit für einen umfangreichen Test immer weiter. Für agile Projekte mit festen Iterationen durch Sprints ergibt sich ein weiteres Problem: Hier wird die Anzahl der zu prüfenden Funktionen mit jedem Sprint größer.
Reine klassische manuelle Tests kommen hier an ihre Grenzen. Darum sollten Tester und Entwickler gemeinsam an einer Testautomatisierungsstrategie arbeiten.
Manual Work
Auswirkung
Lösung
• Es gibt nur manuelle Tests
• Späte Rückmeldung bei Fehlern
• QA auf alle Schultern verteilen
• Tester überfordert
• Auf allen Teststufen testen
• Automatisierung einführen
Anti-Pattern – Automatisierte Regressionslücke
Das andere Extrem wäre ein Projekt ohne manuelle Tests. Dies bedeutet zwar eine hohe Integration in die CI-/CD-Prozesse und eine schnelle Rückmeldung bei auftretenden Fehlern, aber auch vermeidbare Probleme. Eine hohe Rate an Testautomatisierung ist mit einem großen Aufwand verbunden – sowohl bei der Erstellung der Tests als auch bei der Wartung. Und je höher die Komplexität der Anwendungsfälle ist und je schwieriger die verwendeten Technologien sind, desto höher ist die Wahrscheinlichkeit, dass durch Probleme während des Testdurchlaufes dieser stoppt oder aufwendige Prüfungen von Testabweichungen notwendig sind. Außerdem prüfen die meisten automatisierten Tests nur die Regression ab. Durch automatisierte Tests würden somit nie neue Fehler gefunden, sondern nur die Funktionsweise der Altfunktionen geprüft.
Darum sollte immer mit einem gesunden Augenmaß automatisiert werden und parallel durch manuelle und ggf. durch explorative Tests nach neuen Abweichungen Ausschau gehalten werden.
100% Testautomation
Auswirkung
Lösung
• Es gibt nur automatisierte Tests
• Sehr viel Aufwand
• Mit Augenmaß automatisieren
• Alle überfordert
• Manuelles Testen hat seinen Sinn
• Build Stops durch Problemfälle
Anti-Pattern – Testsingularität
Tests aus unterschiedlichen Teststufen und -arten haben jeweils einen unterschiedlichen Testfokus. Damit ergeben sich auch unterschiedliche Anforderungen an die Testumgebung wie Stabilität, Testdaten, Ressourcen etc. Entwicklungsnahe Testumgebungen werden sehr oft mit neuen Versionen versorgt, um die Entwicklungsfortschritte zu prüfen. Für die höheren Teststufen oder andere Testarten benötigt man einen stabileren Versionsstand über eine längere Zeit.
Um nicht ggf. die Tests durch einen geänderten Softwarestand bzw. eine geänderte Version zu kompromittieren, sollte es für jede Testart eine Testumgebung geben.
One Test Environment
Auswirkung
Lösung
• Es gibt nur eine Testumgebung
• Kein Testfokus möglich
• Mehrere Testumgebungen
• Kompromittierte Tests
• Nach Teststufe oder Testfokus
• Keine produktionsnahen Tests
• „Pro Testart eine Testumgebung“
Anti-Pattern – BauManuFaktur
Moderne Entwicklung lebt von einer schnellen Auslieferung und eine zeitgemäße Qualitätssicherung von der Integration der automatisierten Tests in den Build-Vorgang sowie der automatisierten Verteilung des aktuellen Softwarestandes auf die unterschiedlichen (Test-) Umgebungen. Ohne ein Build- oder CI-/CD-Werkzeug können diese Funktionen nicht bereitgestellt werden.
Sofern es in einem Projekt noch Aufgaben zur Bereitstellung eines CI-/CD-Prozesses gibt, können diese am Board als „To Dos“ markiert werden.
No Build Tool
Auswirkung
Lösung
• Es gibt kein Build-Werkzeug
• Keine CI/CD
• CI/CD einführen
• Langsame Auslieferung
• Lücken am Board markieren
• Späte Testergebnisse
• Ressourcenabhängig
Anti-Pattern – Early Adopter
Neue Technologien bringen meist auch neue Werkzeuge mit sich und neue Versionen neue Funktionen. Aber die Einführung neuer Werkzeuge und das Update auf neue Versionen birgt auch ein Risiko. Auch hier ist es ratsam, mit Bedacht vorzugehen und nicht alle Teile/Werkzeuge des Projektes auf einmal zu ändern.
Mit dem QA Navigation Board haben die agilen Entwicklungsteams ein visuelles Hilfsmittel, mit dem sie frühzeitig die planerischen Aspekte der Qualitätssicherung beurteilen können. Dabei kann das QA Navigation Board innerhalb der Projektlaufzeit auch als Referenz des aktuellen Vorgehens und als Ansatz für potenzielle Verbesserung genutzt werden. » QA Navigation Board
Das QA Navigation Board wird innerhalb eines Workshops entwickelt, welcher von einem agilen QA-Coach durchgeführt wird. Der Workshop sollte nicht langer als 1,5 Stunden dauern.
Vorbereitung
Es sollten alle Beteiligten des agilen Projektes eingeladen werden:
Entwicklerteam (Entwickler, Tester)
Scrum Master
Product Owner
weitere Stake- und Shareholder
Das QA Navigation Board wird an einer (Pinn-) Wand befestigt. Zusätzlich wird der QA-Oktant als Arbeitsblatt für jeden Teilnehmer ausgedruckt.
Schritt 1:
Vorstellung des QA Navigation Board und der Ziele des Workshops durch den Moderator (agiler QA-Coach) sowie Vorstellung der Beteiligten.
Schritt 2:
Kurze Vorstellung des QA-Oktanten und der Qualitätskriterien. Ziel ist es, dass alle Beteiligten das Arbeitsblatt ausfüllen können und alle die Qualitätskriterien verstanden haben bzw. nicht anschließend aneinander vorbeireden.
Des Weiteren stimmen sich die Teilnehmer über die Dimensionen des QA-Oktanten ab: Wie sollen die Abstände des Diagrammes bewertet werden (1, 2, 3 oder S, M, L, XL etc.)? Danach werden die Arbeitsblätter ausgeteilt und innerhalb von 5 bis 10 min von jedem Beteiligten alleine ausgefüllt und mit seinem Namen versehen (siehe Blogbeitrag: Wie verwende ich den QA-Oktanten).
Schritt 3:
Nach Ablauf der Zeit sammelt der Moderator die Arbeitsblätter wieder ein und platziert sie auf einer (Pinn-) Wand.
Die Aufgabe des Moderators ist es nun, die einzelnen Qualitätskriterien durchzugehen. Dazu identifiziert er pro Kriterium den gemeinsamen Nenner (Durchschnitt) und bespricht die größten Abweichungen mit den dazugehörigen Personen (siehe Planning poker). Wurde im Team ein Konsens über den Wert des Kriteriums erzielt, wird dieser Wert vom Moderator dokumentiert.
Schritt 4:
Auf Basis der Wertung der Qualitätskriterien leiten nun die Beteiligten die notwendigen Testarten ab. Je wichtiger ein Qualitätskriterium bewertet wurde, desto wahrscheinlicher muss es durch ein passendes Testvorgehen geprüft werden. Die identifizerten Testarten werden vom Team in der Testpyramide des QA Navigation Board platziert.
Schritt 5:
Sind alle Testarten identifiziert und platziert, können die notwendigen Testressourcen und anderen Testartefakte auf dem QA Navigation Board platziert werden. Hier kann eine Checkliste helfen (siehe Blogbeitrag: Die QA-Karte oder „Wie fülle ich das QA Navigation Board…“).
Schritt 6:
Hat das Team das QA Navigation Board weitestgehend ausgefüllt, wird es an einem passenden Platz im Teamraum aufgehängt. Der Moderator schließt den Workshop ab und verweist darauf, dass das QA Navigation Board vom Team weiterentwickelt und auch in den Retrospektiven genutzt werden kann.
Mit dem QA Navigation Board haben die Entwicklungsteams ein visuelles Hilfsmittel, mit dem sie frühzeitig die planerischen Aspekte der Qualitätssicherung beurteilen können. Dabei kann das QA Navigation Board innerhalb der Projektlaufzeit auch als Referenz des aktuellen Vorgehens und als Ansatz für potenzielle Verbesserung genutzt werden. Aber wie lassen sich die Testarten und anderen Testartefakte auf dem QA Navigation Board platzieren?
Um die Frage „Wie und wo wollen wir testen?“ zu beantworten, müsste das Team den gesamten Entwicklungsprozess nach Test- und QA-Aspekten durchforsten und diese dokumentieren. Je nach Projekt kann der Entwicklungsprozess unterschiedlich ausgeprägt sein und damit die Fragestellung schnell recht komplex werden lassen.
Abbildung 1: Entwicklungs- und QA-Prozess
Um auch hier den Teams einen mühelosen Einstieg in das Thema zu geben, haben wir die QA-Karte entwickelt. Die QA-Karte bietet dem Team eine praktische Möglichkeit, die Maßnahmen für eine optimale Testbarkeit der Projekte zu planen und zu dokumentieren. Ziel ist es, bereits zu einem frühen Zeitpunkt alle QA-relevanten Fragen für die Teams und Entwicklungsprojekte durch einen spielerischen Ansatz zu ermitteln.
Abbildung 2: Die QA-Karte
Nach der Definition der Testschwerpunkte durch die Nutzung des QA-Oktanten und der Bestimmung der notwendigen Testarten können alle Aspekte der Teststrategie wie Testarten, Ressourcen und Werkzeuge visualisiert, diskutiert und priorisiert werden.
Als Good-Practice der durchgeführten Workshops kristallisierte sich heraus, dass es hilfreich ist, bei der Steuerung der Befüllung der QA-Karte zwei Hilfsmittel zu nutzen. Zum einen einen guten Moderator, der den Workshop in die richtige Richtung leitet und zum anderen die Nutzung einer Checkliste. Die Checkliste beinhaltet passende Fragen, die im Workshop als Anregung dienen sollen, um die verschiedenen Teile der QA-Karte zu befüllen. Diese Fragen sind nachfolgend aufgelistet und dem jeweilig zu befüllenden Feld zugeordnet.
Requirements
Wo liegen die Anforderungen?
Unterstützen die Anforderungen die Testfallerstellung?
Lassen sich Anforderungen und Tests verknüpfen?
Test / Code
Wo werden die Tests platziert?
Haben wir die nötigen Skills?
Repository
Wo werden die Testartefakte gespeichert?
Gibt es unterschiedliche Artefakte?
Test Management
Wie planen wir unsere Tests?
Wie dokumentieren wir unsere Tests?
Wie informieren wir? Und wen?
Automation
Wieviel Testautomatisierung ist nötig?
Benötigen wir weitere Werkzeuge?
Benötigen wir Testdaten?
Build
Wie oft wollen wir bauen und testen?
Wie wollen wir die QA integrieren?
Wollen wir Wartbarkeit prüfen?
Test Environments
Haben wir für jeden Test die passende Umgebung?
Kommen wir uns in die Quere?
Abbildung 3: Beispiel 1 eines ausgefüllten QA Navigation BoardsAbbildung 4: Beispiel 2 eines ausgefüllten QA Navigation Boards
Sobald alle Testarten ausgewählt wurden und das Team begonnen hat, die anderen Testartefakte (z.B. Werkzeuge, Umgebungen) zu platzieren, kann sich der Moderator zurückziehen. Das finale Wandbild sollte vom Team plakativ im Teamraum angebracht werden. So dient das QA Navigation Board als Referenz des aktuellen Vorgehens und als Ansatz für potenzielle Verbesserung.
In meinem Blogartikel „QA Navigation Board – Wie, wir müssen das noch testen?“ habe ich das QA Navigation Board vorgestellt. Nun möchte ich unsere Erfahrungen teilen, wie sich der darin enthaltene QA-Oktant bei der Suche nach den notwendigen Testarten nutzen lässt.
Eine der Fragen zu Beginn eines Softwareprojektes ist, auf welchen Qualitätskriterien der Fokus der Entwicklung und damit auch der Qualitätssicherung liegt. Um den Teams einen einfachen Einstieg in das Thema zu geben, nutzen wir den QA-Oktant. Folgend der ISO 25010 beinhaltet der QA-Oktant die Qualitätskriterien für Softwaresysteme. Sie geben aber auch einen Hinweis auf die notwendigen Testarten, welche sich aus der gesetzten Gewichtung der unterschiedlichen funktionalen und nichtfunktionalen Kriterien ergeben.
Je nachdem wie stark die umgesetzten Anforderungen auf die Qualitätskriterien einzahlen, ergibt sich die Notwendigkeit, diese Qualitätskriterien mit einer entsprechenden Testart zu prüfen. So benötigen Apps mit hohem Datendurchsatz Effizienztests und Webshops Prüfungen zur Kompatibilität in verschiedenen Browsern. Durch die einfache Visualisierung und Gewichtung der unterschiedlichen Qualitätskriterien kann der QA-Oktant für die Planung genutzt werden.
Das Team stellt dem Product Owner oder dem Fachbereich die Frage „Wie wichtig sind die einzelnen Qualitätskriterien?“. Ziel der Fragerunde ist es, eine Abstufung in der Gewichtung der verschiedenen Kriterien erkennbar zu machen. Dabei werden die meisten Befragten keine große Abstufung zwischen den Qualitätskriterien machen oder besser gesagt wird die Antwort lauten: „Alles ist wichtig!“.
Das Team bzw. der Moderator des Meetings haben nun die Aufgabe, die Fragestellung dahin zu konkretisieren, dass eine Differenzierung erfolgen kann. Dazu können verschiedene Fragetechniken zum Einsatz kommen.
Es kann eine Differenzierung nach Abgrenzung über das Einsatzgebiet erfolgen. Erfolgt der Einsatz einer fachlichen Anwendung auf HTML-Basis in einem Firmennetz und gibt es laut IT-Compliance nur einen Browser und nur eine Betriebssystemversion, dann können der Aspekt Kompatibilität und die damit verbundenen Tests niedriger eingestuft werden. Gibt es dagegen eine hohe Anzahl an Kombinationen von Plattformen, müssen umfangreiche Tests eingeplant werden.
Für weitere Differenzierung kann zum Beispiel eine Negativfragetechnik eingesetzt werden: „Was passiert, wenn z. B. die Benutzbarkeit herabgesetzt wird?“. Für eine Anwendung zur monatlichen Rechnungsstellung wird angenommen, dass die negative Auswirkung der Benutzbarkeit die Geschwindigkeit der Erstellung einer Rechnung von zwei auf vier Stunden erhöht. Da die Anwendung nur einmal im Monat benutzt wird, wäre diese „Verzögerung“ vertretbar und die Benutzbarkeit kann im QA-Oktanten niedriger eingestuft werden.
Diese Fragetechnik kann durch Priorisierung durch Risikoabschätzung erweitert werden: „Was passiert bzw. welche Auswirkungen ergeben sich, wenn z. B. das Kriterium Sicherheit verringert wird?“. Die Antworten ergeben sich hier aus folgenden Aspekten:
Welche monetäre Auswirkung hätte ein Ausfall der Anwendung, wenn der Fokus auf das Kriterium verringert wird?
Wie viele Anwender wären betroffen bei dem Ausfall der Anwendung, wenn der Fokus auf das Kriterium verringert wird?
Wäre Leib und Leben gefährdet bei dem Ausfall der Anwendung, wenn der Fokus auf das Kriterium verringert wird?
Würde die Firma Reputation verlieren beim Ausfall der Anwendung, wenn der Fokus auf das Kriterium verringert wird?
Liegen Ergebnisse und Erkenntnisse bei einem oder mehreren Qualitätskriterien vor, kann man diese mit den offenen Qualitätskriterien vergleichen und wie beim Komplexitätsvergleich im Planning oder der Estimation agieren.
Mit der richtigen Fragestellung ergibt sich eine Übersicht über die Qualitätskriterien. Durch die einfache Visualisierung und Gewichtung der unterschiedlichen Qualitätskriterien kann der QA-Oktant für die Planung der Testarten genutzt werden.
Dabei ist nicht immer nur das Ergebnis der wichtigste Aspekt des QA-Oktanten, sondern auch „der Weg ist das Ziel“. Durch die Gewichtung im Team und gemeinsam mit dem PO und/oder dem Fachbereich können unterschiedliche Meinungen besser wahrgenommen werden und ein besseres Verständnis aller Beteiligten entsteht.
