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.
| Early Adopter | Auswirkung | Lö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 |
Dieser Beitrag wurde verfasst von:
