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.
Im agilen Umfeld tragen Regressionstests dazu bei, die Qualität aufrecht zu erhalten. Mit jeder User Story kommen neu entwickelte Funktionalitäten hinzu, alte Funktionalitäten müssen weiterhin funktionieren. Spätestens nach zehn Sprints ist der Regressionsaufwand so hoch geworden, dass man mit manuellen Tests nicht mehr alles nachtesten kann. Also bleibt nur eines: Testautomatisierung.
Ein Projekt, das auf der grünen Wiese entsteht, ermöglicht es, von Anfang an die Testautomatisierung sauber zu integrieren. Gleichzeitig findet man sich im Testumfeld oft als Einzelkämpfer mehreren Entwicklern gegenüber. Wie lässt sich also eine zeitintensive Automatisierung der Funktionalitäten im alltäglichen Doing eines Test Analysten realisieren?
Umfeld in unserem Projekt
In unserem Projekt erstellen wir eine neue Software im JavaScript-Umfeld. Umgesetzt wird diese mit dem Electron Framework. Für die Automatisierung von Testfällen ist dadurch Spectron als Mittel der Wahl gesetzt. Als Projektplattform wird Jira genutzt und das Projekt wird nach dem SCRUM-Modell durchgeführt. Das Projektteam besteht aus (bezogen auf Vollzeit-Tätigkeit):
6 Entwicklern inkl. 1 Architekt
1 Scrum Master
1 Business Analyst
1 ½ Testern
Ansatz
Bereits zum Kick-off des Projektes war absehbar, dass die Testautomatisierung durch die Tester nicht geleistet werden kann. Daher hat sich das Team folgende Lösung überlegt:
die Testautomatisierung erfolgt durch die Entwickler
der Review für die Testfälle erfolgt durch die Tester
die Erstellung und die Abnahme der Spectron-Testfälle wird in der Definition of Done festgeschrieben
Vorteile
Zeiteinsparung Test: Der eigentliche Grund für dieses Vorgehen ist die Ressourcenknappheit seitens der Tester. Hätten diese auch die Automatisierung übernehmen müssen, wäre das Ganze nicht möglich gewesen.
Perspektivwechsel Test: Die Tester können im Gespräch und im Review einiges lernen. So wird bei Fragen, warum ein Test so geschrieben wurde, die Umsetzung verständlicher. Dadurch entstehen auch Testfälle, an die man sonst nicht gedacht hätte.
Know-how-Entwicklung: Da es zum Alltag des Programmierers dazugehört, entwicklungsbegleitende Tests zu schreiben, ist das Grundverständnis für die Erstellung der automatisierten Tests sehr hoch. Bei unserem Projekt ist dies bereits mehrfach von Nutzen gewesen:
Teile der Anwendung konnten mit technischen Kniffen abgedeckt werden, die ein Tester nicht ohne Weiteres hätte liefern können. Ein Beispiel hierfür ist die automatisierte Prüfung der korrekten Darstellung einer Punktewolke in einem Chart und die Anzeige der Details eines gewählten Punktes.
Über technische Refinements konnten die Performanz und die Stabilität der Spectron-Tests deutlich verbessert werden.
Nach veränderter Toolauswahl dauerte die Ausführung eines kompletten Spectron-Durchlaufes eine halbe Stunde weniger (25% Zeiteinsparung).
Perspektivwechsel Entwicklung: Dadurch, dass der Entwickler sich mit der Sichtweise eines Nutzers auf die Funktionalität und die Oberfläche der Software beschäftigt hat, konnte eine Vielzahl von Fehlern vermieden werden und das Grundverständnis stieg durch den regen Austausch mit den Testern.
Nachteile
Erhöhter Zeitaufwand Entwickler: Was an einer Stelle an Zeit eingespart wird, wird an anderer Stelle wieder benötigt. Der Aufwand kann aber in diesem Fall auf mehrere Schultern verteilt werden.
Gliederung: Entwickler gliedern Testfälle in technisch logische Bereiche. Da dies nicht immer identisch zur fachlichen Logik ist, kann es für die Tester schwer werden, bestimmte Testfälle wiederzufinden und zu überprüfen.
Herausforderungen und Lösungen
Traceability DEV-QA: Der Review findet im Projekt im git (Diff-Tool) statt. Im Projekt wurden angepasste und angelegte Spectron-Testfälle durch das Test-Team gereviewed, gelöschte Testfälle aber nicht – in der Annahme, dass diese bei der Anpassung ersetzt wurden. Dadurch waren Requirements nicht mehr abgedeckt. Lösung: Um den Problemen im Review entgegenzutreten, ist ein Training für den Umgang mit git für alle, die im git arbeiten und reviewen müssen, besonders hilfreich. Auch ein Walkthrough zwischen Test- und Entwicklungsteam bei großen Anpassungen bring einen Mehrwert, damit die Tester besser verstehen, was die Entwickler umgesetzt haben.
Abbildung 1: Beispiel für Git-Review
Traceability-Spectron-Anforderungen: Diese Herausforderung ist speziell in unserem Projektumfeld entstanden. Das agile Team verwendet für das Anforderungs- und Testmanagement Jira, während im Umfeld des Kunden aus rechtlichen Gründen die Anforderungen und Testfälle in einer separaten Anforderungsmanagementsoftware spezifiziert werden müssen. Da die Systeme sich nicht kennen, ist eine automatische Traceability nicht gewährleistet. Lösung: Um dieser Hürde entgegenzuwirken wurde eine direkte Zuweisung der Req-ID in die Spectron Cluster eingeführt.
Abbildung 2: Beispiel für direkte Zuweisung
Fazit
Abschließend lässt sich sagen, dass sich in unserem Projekt der Ansatz bewährt hat, den Test Analysten automatisierte Testfälle nur reviewen zu lassen, statt sie selbst zu schreiben. Die Aufgabenteilung zwischen Testern und Entwicklern fügt sich sehr gut in die agile Vorgehensweise (Scrum) ein. Die Vorteile überwiegen die Nachteile somit bei Weitem.
Dieser Ansatz ist sehr gut geeignet für ein agiles Projekt mit schmalem Staffing und hohem Qualitätsanspruch, das auf der grünen Wiese startet. Man sollte diesen Ansatz aber von Beginn an verfolgen. Ein nachträgliches Aufsetzen ist kaum noch möglich, da eine sukzessive Erweiterung der Testfälle nach jeder User Story deutlich übersichtlicher und einfacher ist als Testfälle en bloc zu erstellen. Des Weiteren werden bereits zu Beginn Entscheidungen in der Umsetzung, der Gliederung, der Architektur und vor allem in den Prozessen (Definition of Done, …) getroffen.
Wenn sich ein externer Testdienstleister und der Kunde über den Umfang des nächsten Testprojektes abstimmen, nutzen sie eine Testkostenschätzung. Das Erstellen einer möglichst genauen und von allen Beteiligten akzeptierten Testkostenschätzung stellt aber meist eine Herausforderung dar. Dafür gibt es zwei Gründe – der Zeitpunkt der Erstellung und die festgelegten Parameter zur einzelnen Bewertung von Testszenarien bzw. Testfällen. Die meisten werden sich nun sicher die Frage stellen, wie es mit dieser Problemstellung zu genannter Überschrift gekommen ist. Diese Erkenntnis beruht auf meinen bisherigen Erfahrungen beim Erstellen von früheren Testkostenschätzungen. Dabei kam es immer wieder zu den gleichen Grundsatzdiskussionen und Anpassungen der erstellten Testkostenschätzungen. Darauf wird später noch einmal eingegangen. Zunächst werden die Grundlagen für eine Testkostenschätzung beschrieben.
Grundlagen der Testkostenschätzung
Für die Abrechnung von Testdurchführungen durch den Testdienstleister gegenüber dem Auftraggeber gibt es unterschiedliche Varianten. Bisher sind davon zwei in meinen Projekten, in denen ich Testkostenschätzungen erstellt habe, zum Einsatz gekommen: Zum einen über T&M-Basis (time and material), zum anderen über die Komplexität der durchzuführenden Testszenarien.
Die erste Möglichkeit besteht darin, die Testdienstleistung anhand des Zeit-Aufwandes (Personen-Tage) abzurechnen. Dabei werden die erforderlichen Tage beziehungsweise Stunden und die benötigte Anzahl an Testern für die Testdurchführung geschätzt.
Da sich diese Art der Testaufwandschätzung meistens auf einen vorgegebenen Zeitraum bezieht, gibt es keine Zuordnung zu bestimmten Szenarien bzw. Testfällen. Daraus ergibt sich, dass diese Schätzung im Allgemeinen durch den Auftraggeber in dem vollen Maße akzeptiert und auch beauftragt wird.
Abbildung 1: Erfolgreiches Verhandeln
Die zweite Variante, auf welche sich dieser Beitrag bezieht, ist die Abrechnung auf Basis der Testszenarien und des Aufwands über ein Komplexitätsmodell. Dabei werden im ersten Schritt, anhand der durchzuführenden Testaktivitäten, die erforderlichen Testszenarien identifiziert. Im zweiten Schritt werden die zugehörigen Testfälle ermittelt und dem jeweiligen Szenario zugeteilt. Diese Szenarien bilden im besten Fall einen Geschäftsprozess ab und laufen somit über mehrere, im Unternehmen befindliche Systeme. Solch ein Prozess könnte exemplarisch über die folgenden Systeme führen:
Kundenverwaltungssoftware (interne Nutzung durch Auftraggeber)
Dokumentenablage (interne Nutzung durch Auftraggeber)
Abrechnungssoftware (interne Nutzung durch Auftraggeber)
Geräteverwaltung (interne Nutzung durch Auftraggeber)
Kundenportal (externe Nutzung durch Kunden)
Gerätenutzung (externe Nutzung durch Kunden)
zusätzliche Prüfungen in Datenbanken
Daraus folgt meist, dass unterschiedliche Geschäftsprozesse einen unterschiedlich hohen Aufwand bei der Testdurchführung bedingen. Neben der trivialen Betrachtung des direkten Testaufwandes muss berücksichtigt werden, dass nicht nur die reine Testdurchführung den eigentlichen Aufwand darstellt, sondern bereits die zu erfüllenden Vorbedingungen (z. B. bestimmte Datenkonstellationen) in den Aufwand mit eingerechnet werden müssen.
Ebenso kann es zu einer höheren Testaktivität kommen, sobald weitere Unterstützung durch den Auftraggeber während der Testdurchführung benötigt wird. Denn aufgrund von Abstimmungen bzw. Verfügbarkeiten der jeweiligen Mitarbeitenden des Unternehmens verlängert sich der zeitliche Aufwand. All diese Aspekte haben einen direkten Einfluss auf den Aufwand der Testdurchführung.
Komplexität bestimmen
Um den Aufwand und damit auch den Preis eines Szenarios für die Testdurchführung zu ermitteln, müssen wir die Komplexität der zu erledigenden Testaufgaben bestimmen. Dazu wurden in den vergangenen Projekten unterschiedliche Herangehensweisen genutzt.
Die erste „einfache“ Variante war die Bestimmung der Komplexität innerhalb von drei Klassen (kleines Szenario, mittleres Szenario oder großes Szenario). Aber auch dort gab es für bestimmte Szenarien mit dem Auftraggeber abgestimmte Ausnahmen, welche mit einem höheren Aufwand beziffert wurden, da zusätzliche externe Dienstleister bei der Testdurchführung beteiligt waren.
Für eine genauere Bestimmung der Komplexitäten wurde eine ausführlichere Variante mit breiterer Komplexitätskategorie erarbeitet und eingeführt. Diese erweiterte Einteilung reicht von “1” für ein sehr kleines Szenario bis zu “9” für ein sehr aufwendiges Szenario unter Beteiligung von externen Dienstleistern.
Abbildung 2: Abstimmung zwischen Auftraggeber und Dienstleister
Zur Bestimmung der Kategorie für ein Szenario wurden die drei folgenden Bereiche innerhalb eines einzelnen Szenarios festgelegt:
Aufwand für Testvorbereitung
Aufwand für Testdurchführung
Aufwand für Testspezifikation
In diesen drei Bereichen werden jeweils eine gewisse Anzahl an Punkten vergeben, die sich am zeitlichen Aufwand orientieren. Die Summe der gesamten Punkte aus diesen drei Bereichen ergibt mit Hilfe eines Umrechnungsschlüssels die Komplexität eines Szenarios.
Probleme bei der Testkostenschätzung
Nachfolgend werden Probleme bei der Testkostenschätzung beschrieben bzw. Gegebenheiten, die dazu führen, dass nach erstellter Schätzung oft ein Handeln um die Kategorien der Szenarien beginnt.
Aus Sicht des Auftraggebers ist klar, dass es in den meisten Fällen um die Kosten der Testdurchführung geht und diese möglichst geringgehalten werden sollten, ohne den Testumfang zu mindern.
Da eine Testkostenschätzung zeitlich weit vor der eigentlichen Testdurchführung erstellt werden muss, stehen in den meisten Fällen noch keine genauen Spezifikationen zur Verfügung. Im besten Fall sind bereits erste Versionen von Fachkonzepten vorhanden. Diese verfügen jedoch oft noch nicht über die komplette Systemlandschaft, welche von der Softwareanpassung betroffen ist. Die noch fehlenden Dokumente wirken sich negativ auf die folgenden Punkte aus.
Bei der Testkostenschätzung wird der Testaufwand eines Szenarios aufgrund der bisherigen Durchführungen ermittelt, bzw. bei neuen Themen geschätzt und entsprechend eingestuft. Da in den einzelnen Bereichen (z. B. Aufwand für Testdurchführung) eine Schätzung auf Grundlage des zeitlichen Aufwandes durchgeführt wird, kommt es immer wieder zu Diskussionen über die geschätzten Zeiten und der damit verbundenen Kategorie eines Szenarios. Der Auftraggeber ist nach dem Prüfen der Schätzung nicht selten der Meinung, dass es möglich ist, die Tests eines Szenarios in kürzerer Zeit durchzuführen. Oft setzt er diese Meinung durch und die Testkostenschätzung wird angepasst – erstes Handeln erfolgreich abgeschlossen.
Diese kleineren Abweichungen können durch erfahrene Tester, welche die beteiligten Systeme in- und auswendig kennen und somit schneller bei der Testdurchführung sind, ausgeglichen werden. Unerfahrene Tester, welche bei einem oder mehreren Systemen innerhalb des Szenarios nicht über das Expertenwissen verfügen, benötigen etwas mehr Zeit, wodurch bereits die erste Diskrepanz zwischen dem geschätzten und dem tatsächlichen Aufwand entsteht.
Eine weitere Diskrepanz entsteht bei Änderungen an der Software über mehrere Systeme, durch die der Aufwand für das Herstellen der Testvorbedingungen steigt. Dies kann daraus folgen, dass bestimmte Datenkonstellationen nicht mehr ohne Weiteres im Vorsystem erzeugt werden können. Dies geschieht z. B. durch den Wegfall von Schreibrechten auf einer Datenbank. Da in diesem Projekt regelmäßige Softwareanpassungen (halbjährlich) durchgeführt werden, entstehen nach einer gewissen Zeit immer wieder Szenarien, welche den gleichen Geschäftsprozess abbilden. Diese bisherigen Schätzungen werden zum Vergleich herangezogen. Somit werden auch kleinere zusätzliche Aufwände, wie der Mehraufwand beim Herstellen der Testvorbedingungen, in der Kategorie gesenkt. Die Testkostenschätzung wird angepasst – zweites Handeln erfolgreich abgeschlossen.
Es kann bei der Testkostenschätzung auch zu dem Punkt kommen, dass ein Szenario in der Kategorie zu gering eingestuft wurde. Dies tritt z. B. bei komplett neuen Funktionalitäten in der Software auf, für die es noch keine Erfahrungswerte gibt. Somit wird es nötig, das Szenario bei der nächsten Schätzung in der höheren Kategorie einzuordnen. Diese Erhöhung der Kategorie wird durch den Auftraggeber geprüft, welcher diesbezüglich kaum Erfahrungswerte besitzt und die vorherige Schätzung als Grundlage verwendet. Die Testkostenschätzung wird in diesem Fall nicht angepasst – drittes Handeln erfolgreich abgeschlossen.
Dieses Handeln wird nicht bei jeder Kostenschätzung mit allen Szenarien durchgeführt, kommt aber bei jeder Schätzung mit einzelnen Szenarien immer wieder einmal vor.
Fazit
Eine Testkostenschätzung auf Grundlage von zeitlichen Aufwänden sollte aus meiner Sicht nur für interne Zwecke beim Testdienstleister zur Ermittlung der Komplexität erfolgen. Denn eine zeitlich abhängige Schätzung für den Aufwand der Testvorbereitung, die Testdurchführung etc. kann nur funktionieren, wenn die einzelnen notwendigen Parameter auch messbar und von beiden Seiten festgelegt sind. Unterschiede ergeben sich bereits bei der Durchführung und Protokollierung von Testfällen durch verschiedene Tester. Der erste Tester protokolliert seine Ergebnisse genauer und mit zusätzlichen Screenshots, wohingegen der zweite Tester mittels Copy & Paste aus dem System die Ergebnisse ausreichend protokolliert. Dadurch kann bereits eine Abweichung von +/- 30 Minuten entstehen.
Für eine Testkostenschätzung ist es notwendig, Bewertungskriterien heranzuziehen. Diese sollten aber sowohl für den Auftraggeber als auch den Testdienstleister nachvollziehbar und bewertbar sein. Darüber hinaus muss eine gewisse Vertrauensbasis untereinander gegeben sein, damit eine für beide Seiten überzeugende Schätzung erstellt und akzeptiert werden kann. Denn auch wenn manche Schätzungen von einzelnen Szenarien tiefer eingestuft werden, so gibt es wiederum auch solche, die in der Kategorie höher eingestuft sind. Dadurch kann sich die Testkostenschätzung in der Gesamtheit die Waage halten.
Wenn man einmal eine gemeinsame Basis gefunden hat, erleichtert dies das Arbeiten an einer Testkostenschätzung ungemein. Denn wenn beide Seiten die gleiche Auffassung von dem geschätzten Aufwand vertreten, werden die nachträglichen Anpassungen – das “Handeln wie auf dem Basar” – zum Großteil minimiert.
Als weiterführenden Beitrag zum Remote Pair Testing möchte ich auf das Remote Mob Testing eingehen. In vielen Unternehmen arbeiten die Mitarbeiter an verschiedenen Standorten verteilt, auch innerhalb der Projektteams. Um nicht auf die Benefits des Mob Testings verzichten zu müssen, kann man Gebrauch von der verteilten Variante machen.
Zuallererst ist es wichtig, den Ansatz des Mob Testings zu verstehen. Hierbei handelt es sich um eine kollaborative und explorative Methode. Diese kann bspw. genutzt werden, um das Testwissen in den Teams zu verteilen oder mit dem Team gemeinsam zu automatisieren oder neue Technologien einzusetzen.
Die Rollen beim Mob Testing
Das Mob Testing besitzt vier verschiedene Rollen:
Der Driver ist für die Umsetzung der Testideen verantwortlich. Er befolgt die Angaben des Navigators und darf sich dabei nicht in die Testidee einmischen.
Der Navigator hingegen ist die Person, welche die Testidee hat und die Ansagen hierzu macht. Er erklärt dem Driver, wie und vor allem warum er die Idee umsetzen soll.
Die Mob Mitglieder beobachten das Geschehen und helfen dem Navigator dabei, die Ideen zu entwickeln. Ebenso können sie Fragen stellen.
Der Facilitator steuert die Zeit, rotiert als einzige Rolle nicht, notiert sich Anmerkungen und Auffälligkeiten und ist Moderator und Schiedsrichter. So ist er dafür verantwortlich, dass unnötige Diskussionen unterbunden und hilfreiche Konversationen gefördert werden.
Abbildung 1: Rollen beim Remote Mob Testing
Die Rollen Driver, Navigator und Mob Mitglied rotieren regelmäßig, z. B. wenn eine Testidee umgesetzt wurde oder alternativ nach einigen Minuten. Gemäß der Literatur ist für eine zeitlich indizierte Rotation eine Standardrotationszeit von 4 Minuten vorgesehen. Diese kann allerdings je nach Belieben angepasst werden. Ziel ist es, den aktuellen Navigator nicht mitten in der Testidee zu unterbrechen. Für das Remote Mob Testing gibt es ebenfalls Angaben, die besagen, dass die Remotedurchführung besser funktioniert, wenn die Zeit auf 10 Minuten angesetzt wird. Das soll zu weniger unpassenden Unterbrechungen führen.
Die Rollen beim Mob Testing
Für den Remote-Ansatz empfiehlt sich ebenfalls eine kleinere Gruppe. Eine geeignete Größe umfasst ca. vier bis sechs Personen, so dass es nicht unübersichtlich wird und die Konversation noch sinnvoll stattfinden kann. Die Dauer kann auf 1,5 Stunden angesetzt werden.
Um das Ganze sinnvoll remote durchführen zu können, sollte man sich erst einmal ein geeignetes Kommunikationstool auswählen. Gut funktionieren an dieser Stelle z. B. MS Teams oder Skype. Dabei gibt es unterschiedliche Umsetzungsmöglichkeiten für die Durchführung der Rotation und die daraus folgende Umsetzung durch den Driver.
Beispiele aus der Praxis
Im Folgenden werde ich zwei Ansätze vorstellen, die für mich gut funktioniert haben. Bereits in der Vorbereitung ist es für eine geregelte Rotation ratsam, eine Reihenfolge für den Wechsel festzulegen. Hierfür kann man die Teilnehmer durchnummerieren.
Der 1. Ansatz: Übergabe der Maussteuerung
Hierbei teilt der Facilitator seinen Bildschirm und der Driver fordert dann die Maussteuerung an. Diese wird weitergegeben, sobald ein neuer Driver an der Reihe ist. Dieser Ansatz ist gut geeignet, wenn man an einem Testobjekt arbeitet, welches für ein sinnvolles Weiterarbeiten den Zustand des letzten Drivers benötigt. Zudem ist dies auch mein persönlicher Lieblingsansatz, weil er unkompliziert und schnell funktioniert
Der 2. Ansatz: Übergabe der Bildschirmübertragung
Bei diesem Ansatz teilt jeder Driver seinen Bildschirm, sobald er an der Reihe ist. Dieses Vorgehen eignet sich jedoch nur, wenn am Testobjekt weitere Ideen durchgeführt werden können und zwar unabhängig vom zuvor durchgeführten Test. Denn der letzte Stand des vorherigen Drivers ist auf der neuen Bildschirmübertragung nicht mehr vorhanden. Eine weitere Möglichkeit für diesen Ansatz ist es, einen Zugriff auf das Objekt durch mehrere Personen einzurichten – also z. B. einen User für alle Beteiligten.
Fazit
Bereits das Mob Testing selbst lässt sich einfach anwenden und ist, wie das Pair Testing auch, eine sehr leichtgewichtige Testmethode. Genauso sind die beiden Ansätze (Änderung der Maussteuerung vs. Bildschirmübertragung), die ich in diesem Beitrag vorgestellt habe, unkompliziert und einfach in der Umsetzung. Beide Varianten haben gut funktioniert und ermöglichen das verteilte Zusammenarbeiten.
Für den häufigeren Gebrauch und bspw. das gemeinsame Entwickeln von automatisierten Tests stehen zudem einige Tools zur Verfügung. Will man aber das Testobjekt explorativ erkunden und schnell und unkompliziert verteilt Testen, eignen sich dafür die beiden vorgestellten Varianten sehr gut.
Bei der ZEISS Digital Innovation wird der verteilte Ansatz schon lange gelebt. Gerade zu Corona-Zeiten ist dieser Ansatz gefragter denn je. Die gute Nachricht: Die Arbeit kann auch von zu Hause aus weiter gehen. Aber Remote-Arbeit ist nicht nur im Homeoffice möglich, sondern auch an unterschiedlichen Standorten und Büros.
Das klassische Pairing wird bereits sehr erfolgreich in der agilen Softwareentwicklung eingesetzt. Es ist eine effiziente Methode, um komplexe Aufgaben zusammen zu lösen und das bestmögliche Ergebnis durch das Wissen von zwei Personen zu erzielen. Außerdem ist es ein optimales Hilfsmittel, um Wissen zu verteilen. Durch eine ausführliche Kommunikation der Gedanken und Ideen erreichen beide Teilnehmer am Ende ein ähnliches Know-how-Level. In diesem Beitrag möchte ich daher zeigen, wie die verteilte Zusammenarbeit gelingen kann.
Vorstellung der Methode: Pair Testing
Das Pairing beinhaltet die Aufteilung des Paares in zwei Rollen. Auf der einen Seite gibt es den Driver. Dieser setzt seine Testidee um und teilt seine Gedanken dem Navigator mit. Hierbei erklärt der Driver alles, was er tut, so transparent wie möglich. Dadurch kann der Navigator die Ansätze und Schritte des Drivers nachvollziehen.
Auf der anderen Seite gibt es den Navigator. Dieser überprüft die Eingaben des Drivers und teilt ebenfalls seine Gedanken dazu mit. Dadurch können neue Lösungswege aufgezeigt werden und der Navigator kann durch Fragen seine Unklarheiten beseitigen. So lernen beide voneinander.
Damit jeder die Chance bekommt, die Anwendung zu erleben und seine Ideen umzusetzen, wechseln die Rollen regelmäßig. Der Wechsel erfolgt nach einer abgeschlossenen Testidee oder nach einigen Minuten. Dies wird auch die Rotation der Rollen genannt.
Abbildung 1: Driver und Navigator
Remote Arbeit: Technische Voraussetzungen
Damit beide Parteien remote miteinander arbeiten können, bedarf es einer geeigneten Konferenzsoftware, beispielsweise MS Teams oder Skype. Damit kann das Testobjekt via Screensharing geteilt werden. Für den Arbeitsprozess gibt es zwei Möglichkeiten:
Zum einen kann für die Rollenrotation die Maussteuerung abwechselnd eingefordert werden.
Alternativ kann auch zum Rollenwechsel die Bildschirmfreigabe gewechselt werden. Allerdings benötigen dann beide den Zugriff auf das Testobjekt. Ebenso kann ein Gedanke nicht direkt weitergeführt werden, da sich die Applikation nach dem Wechsel in einem anderen Zustand befindet.
Wenn man den Ansatz des Rollenwechsels nach einigen Minuten verfolgt, kann für das Stoppen der Zeit jede beliebige Stoppuhr-Funktion (bspw. Handy-Uhr) verwendet werden. Jedoch kann das zu Problemen führen, wenn man mitten in der Testidee unterbrochen wird und diese dann ggf. vom neuen Driver weiterverfolgt werden muss. Daher lohnt es sich hier, die Rotation nach abgeschlossenen Testideen durchführen zu lassen.
Pair Testing: Allgemeine Voraussetzungen
Um ein Gelingen des verteilten Arbeitens zu bewirken, gibt es noch andere Aspekte zu beachten.
Die Aufgaben für die Pair-Testing-Session sollten groß und komplex genug sein, so dass sie zu zweit gelöst werden können. Daher ist eine gute Vorbereitung der Session wichtig – hierbei sollten geeignete Aufgabenstellungen zurechtgelegt werden. Diese Inhalte können z. B. Stories sein, die getestet werden sollen.
Fokussierte Zusammenarbeit erfordert viel Konzentration. Daher ist es wichtig, abgestimmte Pausen einzulegen, um wieder Energie zu tanken. Einfache Aufgaben können auch allein schnell und effektiv gelöst werden. Daher ist es ratsam, sich Zeitfenster zu schaffen, in denen Pair-Testing-Sessions für die vorbereiteten Inhalte durchgeführt werden. Das kann dann z. B. bedeuten, dass man einen halben Tag zusammen im Paar testet und die andere Hälfte allein arbeitet.
Zusammenfassung
Pair Testing ist eine leichtgewichtige Methode, die von jedem unkompliziert eingesetzt werden kann. Mit der richtigen technischen Unterstützung ist sie auch remote einfach umzusetzen. So können wir voneinander lernen und uns bei komplizierten Aufgaben gegenseitig unterstützen, trotz weiter Entfernungen. Außerdem hilft die gemeinsame Arbeit, der Remote-Entfremdung vorzubeugen.
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 den beiden vorhergehenden Themen „Zutaten und Küchengeräte für Testomaten und wer ist der Koch“ sowie „Testomaten auf Datensalat an Stressing“ habe ich darüber berichtet, welche Voraussetzungen für die Testautomatisierung gegeben sein müssen und welche Herausforderungen bei den Testdaten gemeistert werden müssen, um erfolgreich Automatisierung einzusetzen. Doch nun stellt sich die Frage, wie denn das Rezept, also ein Testfall für die Testautomatisierung, aussehen muss.
Dazu betrachten wir erst einmal ein typisches Kochrezept. Es besteht im Wesentlichen aus zwei Abschnitten, der Aufzählung der Zutaten (Testdaten) und der Beschreibung, in welcher Reihenfolge die Zutaten verarbeitet werden müssen. Die Beschreibung enthält dann sowohl die Schritte, die zur Zubereitung des Rezepts notwendig sind als auch die Erwähnung der Zutaten aus der Zutatenaufzählung. Nun haben auch Kochrezepte eine unterschiedliche Detailtiefe, je nachdem für wen die Rezepte bestimmt sind. Für den gelernten Chefkoch sind die Rezepte oft weniger detailliert, da der Koch bereits gewisse Arbeitsabläufe kennt und diese nicht näher beschrieben werden müssen. Rezepte für den Privathaushalt oder gar für einen Kochanfänger müssen da schon anders aussehen. So ist das auch bei den Testfällen. Für den Tester mit entsprechendem Domainwissen über die Fachlichkeit seiner Anwendung können die Testfälle weniger detailliert ausfallen. Wie ist das aber für einen Automaten? Dazu vergleichen wir hier einen Bäcker mit einem Brotbackautomaten. Für den Bäcker reicht das Rezept: Backe mir ein Roggenbrot. Für den Backautomaten ist eine genaue Rezeptbeschreibung notwendig – die Reihenfolge, wie die Zutaten in den Automaten gefüllt, welches Programm und welche Temperatureingestellt werden müssen usw.
Da wir in der Qualitätssicherung nicht nur ein Rezept bzw. einen Testfall haben, möchten wir uns jedoch die Arbeit etwas vereinfachen. So wie in der Großküche werden auch wir Vorbereitungen treffen, die uns später die Arbeit erleichtern. Während in der Küche z.B. die Salatbeilage für mehrere Gerichte verwendet wird, werden auch in der Testfallerstellung wiederverwendbare Testfallblöcke erstellt. Dazu werden mehrere Testschritte zusammengefasst und als Testschrittblock zur Wiederverwendung gespeichert. Dieses Verfahren kann sowohl beim manuellen Testen als auch in der Testautomatisierung angewendet werden. Der Unterschied liegt hier jedoch wieder in der Detailtiefe, d.h. dort, wo für das manuelle Testen ggf. eine geringe Detailtiefe ausreichend ist, wird für den Automaten immer die maximale Detailtiefe benötigt.
Abbildung 2: Brot backen
vs.
Abbildung 3: Testfallerstellung
Der Testautomat ist ja so gesehen eigentlich der schlechteste Koch der Welt. Er würde auch das Wasser anbrennen lassen, wenn wir ihm nicht sagen würden, dass der Topf vom Herd muss, wenn das Wasser blubbert. Aber warum benutzen wir dann überhaupt Testautomatisierung? Nun, der Testautomat hat einige wesentliche Vorteile: Ein Koch kann auch mal eine Zutat vergessen oder bei der Abarbeitung des Rezeptes variieren. Das Ergebnis ist dann nicht jedes Mal das gleiche Gericht. Der Automat vergisst hier nichts und hält sich immer an die vorgegebene Reihenfolge des Rezepts. Doch der größte Vorteil des Testautomaten ist die Geschwindigkeit, mit der er die Testfälle durchführen kann. Der Koch benötigt außerdem auch mal eine Pause. Würden wir uns so einen Automaten in der Küche vorstellen, bekämen wir sinnbildlich eine Gulaschkanone, die im Sekundentakt alle möglichen Rezepte abarbeitet und dessen Ergebnis auf den Teller schießt.
Das klingt für die Testautomatisierung sehr verlockend, dabei müssen jedoch immer wieder der Aufwand und der Nutzen ins Verhältnis gesetzt werden. Der Aufwand, so einen Automaten mit den perfekt designten Testfällen (Rezepten) zu füttern, wird oft unterschätzt: Wenn ich nur einmal im Jahr eine Geburtstagsfeier mit zehn Gästen habe, lohnt sich ein Kochautomat sicher nicht. Habe ich dagegen ein Eventunternehmen, welches jeden Tag eine ganze Hochzeitsgesellschaft à la Carte versorgen muss, ist so ein Automat definitiv eine Überlegung wert.
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.
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).
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).
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).
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).
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).
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.
