Der QA Navigation Board Workshop

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.

Download Arbeitsblatt „QA-Oktant“

Die QA-Karte oder „Wie fülle ich das QA Navigation Board…“

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.

Entwicklungs- und QA-Prozess
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.

QA Karte
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 Boards
Abbildung 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.

Wie verwende ich den QA-Oktanten

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.

QA Navigation Board – Wie wir müssen das noch testen?

Meist stehen bei Entwicklungsprojekten die Überlegungen zur Funktionalität und der Mehrwert für den Kunden im Vordergrund. QA und Testbarkeit kommen dadurch bei der Planung zu kurz. So treten während der Testphase Hürden für das Team auf, welche sich durch eine gewisse Voraussicht bei der Planung der QA-Aufgaben umgehen lassen. Tester haben für die Planung der höheren Teststufen bereits ein geeignetes Vorgehen: ein detailliertes Testkonzept, welches die Testziele dokumentiert sowie entsprechende Maßnahmen und eine Zeitplanung festlegt (Abb. 1).

Aspekte der Teststrategie / Inhalte eines Testkonzepts
Abbildung 1: Aspekte der Teststrategie / Inhalte eines Testkonzepts

Diese Detailtiefe eignet sich aber nicht für agile Projekte und Entwicklungsteams. Trotzdem sollte sich das Team vor dem Start eines Projektes über die meisten Aspekte, die im Testkonzept genannt werden, Gedanken machen. Darum haben wir ein Hilfsmittel entwickelt, welches es den Teams ermöglicht, alle Maßnahmen für eine optimale Testbarkeit in Softwareprojekten mit einzubeziehen. Das Hilfsmittel berücksichtigt sowohl die Fragen „Was ist zu testen?“ als auch „Wie und wo wollen wir testen?“.

Um die erste Frage „Was ist zu testen?“ im Hinblick auf Softwareprodukte zu beantworten, ist die Ausprägung der Qualitätskriterien der umzusetzenden Anforderungen ausschlaggebend. Die unterschiedlichen Qualitätskriterien sind in der ISO 25010 „Qualitätskriterien und Bewertung von System und Softwareprodukten (SQuaRE)“ enthalten (Abb. 2).

Qualitätskriterien nach ISO 25010
Abbildung 2: Qualitätskriterien nach ISO 25010

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 verlangen Apps mit hohem Datendurchsatz nach Effizienztests und Webshops sollten auf Kompatibilität in verschiedenen Browsern geprüft werden.

Um den Teams den Einstieg in das Thema zu erleichtern, 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 (Abb. 3).

QA Oktant
Abbildung 3: Der QA-Oktant mit gewichteten Qualitätskriterien

Durch die einfache Visualisierung und Gewichtung der unterschiedlichen Qualitätskriterien kann der QA-Oktant für die Planung genutzt werden. Product Owner können damit die Übersicht über relevante Anforderungen behalten und das Team kann gemeinsam mit dem Product Owner die Anforderungen anhand der Qualitätskriterien einordnen. Durch die Gewichtung im Team können unterschiedliche Meinungen besser wahrgenommen und eine gemeinsame Einordnung anschaulich dokumentiert werden. Aus dem Ergebnis lassen sich die notwendigen Testarten ableiten.

Um die zweite 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 (Abb. 4).

Entwicklungs- und QA-Prozess
Abbildung 4: 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. In Planungsrunden können gemeinsam alle Aspekte der Teststrategie wie Testarten und Werkzeuge visualisiert, diskutiert und priorisiert werden. Neben der Planung dient die QA-Karte mit ihrer plakativen Darstellung auch als Erinnerung oder schneller Einstieg in die Teststrategie des Teams.

Zusammengesetzt ergeben der Oktant und die Karte das QA Navigation Board, welches sich als Wandbild platzieren lässt (Abb. 5).

Das QA Navigation Board mit Oktant und Karte als Wandbild
Abbildung 5: Das QA Navigation Board (mit Oktant und Karte) als Wandbild

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.

Viel Erfolg beim Testen!