Einfache Anamnese der QA-Strategie für agile Teams

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.

QA Navigation Board

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.

QA Navigation Board
Keine TestsAuswirkungenLö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 TestsAuswirkungenLö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.

QA Navigation Board
Angriff der DevOnlyAuswirkungLö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.

QA Navigation Board
Manual WorkAuswirkungLö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.

QA Navigation Board
100% TestautomationAuswirkungLö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.

QA Navigation Board
One Test EnvironmentAuswirkungLö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.

QA Navigation Board
No Build ToolAuswirkungLö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.

QA Navigation Board
Early AdopterAuswirkungLösung
• Einfach immer das neueste …• Herausforderungen in der Einarbeitung• Kein Big Bang
• Skill-Schwächen• Alte Tools kennt man
• Neue Probleme• Skill-Schwächen am Board markieren

Kochrezepte für Testautomatisierung (Teil 2) – Datensalat

Testomaten auf Datensalat an Stressing

Eine besondere Herausforderung für jede manuelle Testdurchführung und ganz besonders für die Testautomatisierung sind die Testdaten. Bei den meisten manuellen Tests stehen in den Testfällen meist nur grobe Hinweise zu den zu verwendenden Testdaten. Das Vorgehen funktioniert in der Testautomatisierung nicht.

Im vorhergehenden Thema „Zutaten und Küchengeräte für Testomaten und wer ist der Koch“ habe ich darüber berichtet, welche Voraussetzungen für die Testautomatisierung gegeben sein müssen, um erfolgreich Automatisierung einzusetzen. Dabei habe ich bereits auf eine weitere Herausforderung hingewiesen: Die Testdaten. Dieses Thema möchte ich in diesem Blogeintrag nun etwas näher beleuchten.

Was passiert, wenn wir uns nicht um die Testdaten bei der Testautomatisierung kümmern und uns auf Testdaten stützen bei denen die Testautomatisierung nicht berücksichtigt wurde?

Testen kann man mit Kochen vergleichen. Das Rezept ist der Testfall und die Testdaten sind die Zutaten. Beim manuellen Testen folgen wir dem Rezept/Testfall und suchen die Zutaten/Testdaten nach Bedarf. Dies funktioniert beim automatisierten Testen nicht. Hier müssen die Testdaten bzw. die Zutaten exakt und vorportioniert vorliegen. Das heißt, es reicht nicht nur die Art und Form der Testdaten zu benennen, sondern es ist notwendig das genau die Instanz des Testdatums im Testskript benannt ist.

Zusätzlich werden beim Testen die Testdaten verbraucht bzw. die Testdaten altern. Also wie im Restaurant, irgendwann sind die Tomaten alle oder der Blattsalat wird welk. Wie bekommen wir also unsere passenden Zutaten und dies auch in einer ausreichenden Menge.

Oft höre ich in Projekten: „Wir machen einfach einen, hoffentlich anonymisierten, Produktionsabzug“. Der liefert jedoch nur einen Teil der benötigten Daten für die Testautomatisierung. Das heißt, für unveränderliche Stammdaten  ist so ein Abzug sehr wohl nützlich. Nun bekommt der Koch in der Küche nicht immer die gleiche Bestellung für seinen Salat. Mal möchte der Gast den Salat mit oder ohne Oliven, mal mit Joghurtdressing, mal mit Essig und Öl. In Abhängigkeit der Zutaten bzw. Änderungen an der Bestellung ändert sich dann auch noch der Preis. Das heißt wir benötigen für unsere Testdaten auch veränderliche Daten so genannte Bewegungsdaten, um die Geschäftsprozesse vollständig abzubilden. Um die benötigten veränderlichen Daten für die Testautomatisierung bereit zu stellen gibt es zwei Ansätze und beide haben ihre Vor- und Nachteile. Beim ersten Ansatz werden die benötigten Daten aus dem anonymisierten Produktionsabzug herausgesucht. Der Aufwand die entsprechenden Filterkriterien zu ermitteln und anschließend in einer Abfrage zu formulieren kann jedoch schnell sehr hoch ausfallen. Der Nachteil ist dabei, dass die herausgefilterten Daten nur in begrenzter Anzahl zur Verfügung stehen und werden bei der Testdurchführung ggf. verbraucht.

Beim zweiten Ansatz werden die benötigten Testdaten in der Datenbank neu erstellt, so dass der Testfall über alle notwendigen Testdaten verfügt. Diese Testdaten werden zwar auch verbraucht, können jedoch durch die automatisierten Skripte immer wieder neu angelegt werden. Auch das Anlegen der so genannten synthetischen Testdaten kann, z. B. bei vielen abhängigen Daten, sehr aufwendig sein. Daher ist immer individuell abzuwägen, welche der beiden Ansätze für welchen Testfall zum Einsatz kommt.

Bei der Testautomatisierung ist es auch oft notwendig die Testdaten zu dynamisieren. Was heißt das? Nehmen wir wieder ein Beispiel aus der Küche. Bekanntlich muss eine gute Pekingente 24h vor dem Verzehr bestellt werden. Da das Verzehrdatum ein veränderliches Datum ist kann hier eine Dynamisierung die Lösung für die Automatisierung bringen. Das Ergebnis sieht dann so aus: Verzehrdatum = Bestelldatum + 24h. Solche oder ähnliche dynamischen Testdaten kommen auch bei der Testautomatisierung zum Einsatz.

Fazit, in den meisten Fällen ist es wie bei einem guten Salat – die Mischung macht‘s. Also hier nochmal das Rezept zusammengefasst. Man nehme als erstes einen anonymisierten Produktionsabzug für die grundlegenden und unveränderlichen Stammdaten (diese können auch bei kleineren Mengen selbst erstellt werden), dazu einige gut ausgewählte veränderliche Daten aus dem Produktionsabzug mittels Abfrage im Testfall. Nun noch eine gut ausgewählte Portion synthetische Testdaten. Das ganze gut abgestimmt mit dem Testfalltemplate. Zum Schluss noch ein Schuss dynamisierte Testdaten im Template oben drauf und fertig ist der perfekte Datensalat für unsere Testautomatisierung. Wichtig nach dem Anrichten der Testdaten in der Datenbank muss die Datenküche auch wieder gut aufgeräumt werden. Also alle statischen, synthetischen und dynamischen Testdaten in den Ausgangszustand bringen, falls sie durch den Testfall verändert wurden. Im Klartext bedeutet dies, dass jeder Testfall in der Nachbedingung ein Aufräumen der Testdaten beinhaltet, denn Sauberkeit ist in einer guten Datenküche oberstes Gebot.

Wie ja bekannt ist, kommen in der Küche auch verschiedene Geräte zur Automatisierung des Kochvorgangs zum Einsatz. Wie viele dieser Testautomaten für ein Projekt gut sind, behandeln wir in meinem nächsten Blogbeitrag aus der Reihe Kochrezepte für Testautomatisierung. Bis dahin happy Testing und immer eine gut aufgeräumte Datenküche.

Kochrezepte für Testautomatisierung (Teil 1) – Suppe

Zutaten, Küchengeräte und wer ist der Koch?

Ein Kollege sprach mich kürzlich an und fragte, ob ich ein Rezept für eine gute Testautomatisierung kenne. Ich sagte, dass man dafür – wie für eine gute Suppe – nicht nur ein Rezept braucht, sondern es kommt auf die Ausstattung der Küche, die Zutaten und den Koch an. Entscheidend für die Testautomatisierung sind also die Projektrahmenbedingungen, die Auswahl der Testwerkzeuge und die Tester die an der Testautomatisierung beteiligt sind.

Wie können wir feststellen, ob die Rahmenbedingungen (nicht verwechseln mit Ramenbedingungen) für die Testautomatisierung gegeben sind? Grundlegend ist hierbei zu unterscheiden, ob sich das Software-Projekt noch in der Vorplanung befindet und die Testautomatisierung von Anfang an eingeplant wird oder ob es sich um ein Projekt handelt, welches bereits läuft und mit Testautomatisierung unterstützt werden soll.

Eines schon vorweg gesagt – je früher mit einer gut geplanten Testautomatisierung begonnen wird, desto wahrscheinlicher wird es eine erfolgreiche Testautomatisierung. Die Gründe liegen oft darin, dass die anfänglichen Aufwände der Testautomatisierung unterschätzt werden und sich der Nutzen rein rechnerisch erst nach Projektende einstellt.

Um dem zu begegnen ist für ein beginnendes Projekt eine gute Planung und für ein laufendes Projekt erst einmal eine Vorstudie der laufenden Prozesse, Testfälle und Rahmenbedingungen notwendig. In so einer Vorstudie sind unter anderem das bereits vorhandene Testfallportfolio, das Testobjekt und die Kenntnisse der Tester zu analysieren und zu bewerten. Auf diese Weise können wir erkennen, wo die eigentlichen Schwachpunkte des Projektes im Testbereich liegen.

Oft wird versucht mit Testautomatisierung Probleme zu lösen, die nichts mit der Testautomatisierung zu tun haben bzw. gegebenenfalls dadurch noch verschlimmert werden. Das ist wie beim Kochen, wenn die Suppe nicht schmeckt wird diese nicht zwingend besser, wenn wir einfach den Koch durch einen Automaten austauschen. Oft wird das Ergebnis sogar schlechter, wenn ich den Kaffeeautomaten im Flur betrachte. Wichtig ist, dass die Voraussetzungen für die Testautomatisierung eine Mindestqualität erreicht haben, bevor mit der Toolauswahl oder gar der Automatisierung begonnen werden kann. Die Testautomatisierung ist der Sahneklecks auf der Suppe, d. h. Testautomatisierung ist nur in einem gut funktionierenden Testprozess erfolgreich. Auch die Testfälle müssen eine ausreichende Detailtiefe zur Automatisierung haben. Die benötigte Detailtiefe ist davon abhängig in wie weit der Tester die nötigen fachlichen Kenntnisse zum Testobjekt mitbringt. Hier könnte der eine oder andere auf die Idee kommen gleich die Fachseite – also die die das Fachwissen haben – die Testautomatisierung machen zu lassen. Das ist meist keine gute Idee, da den Mitarbeitern die Zeit fehlt. Zum einen steht ihre tägliche Arbeit in der Priorität immer höher als die Testautomatisierung und zum anderen müssen die Toolkenntnisse und Testerfahrungen erst aufgebaut werden. Daher empfiehlt es sich, dass die Fachseite die manuellen Testfälle in einer ausreichenden Detailtiefe liefert, welche der Tester auch ohne Domainwissen versteht. Anschließend nimmt der Tester mit seiner Testerfahrung und der nötigen Toolkenntnis die Automatisierung vor.

Es ist illusorisch alles automatisieren zu können, darum wird in der Vorstudie ein Priorisierung der Testfälle vorgenommen. Dabei ist auch das Testobjekt bzw. die zu testende Software auf Automatisierbarkeit zu prüfen. Besonders problematisch für die Testautomatisierung sind z. B. dynamische Objekt-IDs, die sich bei jedem erneuten Aufruf ändern.

Wie wir auch aus der Küche bereits kennen, ist dann auch noch der Koch wichtig, d. h. der Tester, der die Testautomatisierung durchführt. Zum einen benötigt dieser das nötige Toolwissen und zum anderen muss er auch entscheiden können, wo sich die Testautomatisierung im Einzelnen lohnt. Zum Beispiel macht es keinen Sinn eine Funktion in der Software zu automatisieren, die nur extrem selten benötigt wird und im Automatisierungsaufwand sehr hoch ist.

Darum sollte man sich immer an das Rezept halten:

  • mit gutem Augenmaß und einem Gespür für den Aufwand eine ausgewogene Komposition – Kosten und Nutzen im Auge behalten
  • nicht nur auf die Technik verlassen – auch das eigene Handwerk ist wichtig
  • Testautomatisierung funktioniert nur, wenn vorher die grundlegenden Testaufgaben und Prozesse funktionieren – erst Zwiebeln schneiden lernen und dann mit der Bouillabaisse anfangen

Eine weitere Herausforderung für die Testautomatisierung sind die Testdaten. Hierzu aber mehr in meinem nächsten Blogbeitrag. Bis dahin wünsch ich schon mal ein Frohes Fest und überlasst die Weihnachtsgans nicht achtlos einem Automaten.