Warum Agile Testing seines Namens würdig ist

Einführung

Im letzten Artikel haben wir beschrieben, was Agile Testing ist und welche Vorteile es mit sich bringt.

Wir sind nur kurz darauf eingegangen, dass Agile Testing sich wirklich seinen Namen verdient hat. Du könntest dir gerade denken: “Ich und mein Team machen doch Agile”.

Ganz abgesehen von der Tatsache, dass “Do Agile” ≠ “Be Agile”, trifft leider Folgendes auf viele agile Teams zu:

• Testing gilt als die letzte Aktivität eines Implementierungszyklus. Meistens erhalten die Tester das Testobjekt in der letzten Phase und sollen das gesamte Testing in sehr begrenzter Zeit abschließen. Deployments in der Nacht oder Deployments ohne ausreichende Tests sind nicht ungewöhnliche Szenarien. Laut Jeff Sutherland schaffen es 80% der Unternehmen in der Sillicon Valley kein Inkrement nach einem regulären Sprint zu liefern, was wiederum heißt, dass die Software nicht (genug) gestetet wird. Zum Nachlesen hier: What Silicon Valley Needs. Wie sieht es bei euch aus?
• Entwickler und Tester arbeiteten als getrennte Teams oder sogar gegeneinander.
• Die Überprüfung der Testfälle wird ausschließlich von den QA-Mitarbeitern durchgeführt. Damit die QA-Fachkräfte weiter Fehler finden können, werden die QA-Testfälle mit den Entwicklern nicht geteilt. Beide Gruppen lernen, wenn überhaupt, nur begrenzt voneinander.
• Die Hauptaufgabe der Tester besteht darin, Mängel und Defekte aufzuspüren, und ihre Leistung wird anhand der Anzahl festgestellter gültiger Fehler und Defekte beurteilt.
• Die manuellen bzw. explorativen Tests gelten als undankbare Aufgabe.
• Automatisierung gilt als eine Endaktivität und konzentrierte sich hauptsächlich auf die Benutzeroberfläche. Die Regressionssuite gilt als bester Kandidat für die Automatisierung.
• TDD, BDD, ATDD sind Fremdbegriffe.

Die aufgeführten Beispiele haben mit Agile nichts zu tun. Was wirklich Agile ist, lässt sich vom Agilen Manifest ableiten. Obwohl heutzutage Diskussionen geführt werden, ob das agile Manifest noch zeitgemäß ist, (das Thema wird in diesem Podcast diskutiert: ‎Agile Coaching Network: Is it really back-to-basics for…) glauben wir bei Pragtics fest daran, dass es so ist. Die Ausführung ist hier entscheidend. Wenn Testing zum integralen Teil der Herstellung von funktionierender Software gehört, warum soll es sich nicht an agile Werte und Prinzipien orientieren?

Agile Testing als Spiegelung des agilen Manifests

Wie entspricht Agile Testing dem agilen Manifest?

Agile betont die Bedeutung von Teammitgliedern und ihrer Zusammenarbeit gegenüber komplexen Prozessen und Werkzeugen. Dies gilt auch für Tester, die kontinuierlich mit dem gesamten Team interagieren, statt nur Informationen von Entwicklern oder Stakeolder zu erhalten. Agile Tester sind in Anforderungen, Design und Entwicklung involviert, wirken als Mitbesitzer von User Stories und tragen dazu bei, Qualität in das Produkt zu integrieren. Tools werden selektiv eingesetzt, um Prozesse zu unterstützen. Der Fokus soll darauf liegen, dass Prozesse und Tools das agile Team unterstützen, ohne den Prozess zu kompliziert zu machen oder zu formalisieren. Der Umstieg auf Agile Testing verlangt viel von den Entwicklern. Die QA-Ingenieure haben hier eine Schlüsselrolle, in der sie als Mentoren und Förderer agieren.

Lange Dokumente waren gestern. Heutzutage wollen wir uns auf funktionierende Software konzentrieren. Dies kann durch die Zusammenarbeit des ganzen Teams erreicht werden, wenn man alle und vor allem die QA-Ingenieure in das Verfassen von Definition of Ready und Definition of Done einbezieht. Gepaart mit Einzeilern für Testszenarien in den User Stories, explorativen Tests oder Fehler-Checklisten ergibt sich eine ausreichende - schön knackige - Dokumentation für Tests.

Der dritte agile Wert scheint auf den ersten Blick ein wenig herausfordernd in Bezug auf das agile Manifest. Wie kann ich den Kunden in das Agile Testing einbinden? Ohne die Mitbestimmung des Kunden können wir nicht von Agilität reden. Hier ist ein wenig Umdenken mithilfe geeigneter Methoden nötig. Und verschiedene Blickwinkel. Wir haben schon einmal festgehalten, dass es von Vorteil ist, die QA-Ingenieure in die Formulierung der Definition of Done und der Akzeptanzkriterien zu involvieren. User Stories sind die Wünsche des Kunden. Darüber hinaus eignen sich diese Kollegen perfekt dazu, durch explorative Tests auf andere Aspekte des Produkts hinzuweisen. “Ja, das Produkt mag wie erwartet funktionieren, aber muss es so lange dauern bis…” oder “Es funktioniert toll, aber intuitiv geht anders. Ich schlage vor…”. Agile Tester behalten alles im Blick, wenn sie sich durch die Software durchklicken. Eine weitere Methode, die die Sicht der Kunden einschließt, ist die Behavior Driven Development (BDD). Bei BDD Testing liegt der Fokus darauf, das Verhalten einer Software aus der Perspektive der Endbenutzer oder Stakeholder zu verstehen und zu testen. Es geht darum, sicherzustellen, dass die Software das gewünschte Verhalten aufweist und den Anforderungen der Benutzer entspricht. Stell dir das als ein Treffen von drei Amigos vor, die für den Kaiser arbeiten. “Der Kunde ist König” war gestern. Heute ist der Kunde ein Kaiser und agile Testing ist kaiserzentriert.

Agile Testing bietet eine gute Grundlage für die Antwort auf Veränderungen. Was ist damit gemeint? In agilen Umgebungen können sich Anforderungen und Prioritäten während des Entwicklungsprozesses ändern. Agile Testing betont die Flexibilität bei der Auswahl von Testaktivitäten. Je nach den aktuellen Anforderungen und Änderungen im Projekt können Tester ihre Schwerpunkte verschieben und unterschiedliche Testmethoden anwenden, um effektiv auf Veränderungen zu reagieren. Agile Tester passen ihre Testpläne kontinuierlich an, um sicherzustellen, dass sie den aktuellen Bedürfnissen und Zielen des Projekts entsprechen. Die Automatisierung ermöglicht eine schnelle Regressionstestdurchführung, selbst bei häufigen Änderungen. Wenn sich etwa eine Funktion ändert, müssen die entsprechenden automatisierten Testskripte aktualisiert werden, um sicherzustellen, dass die bestehenden Funktionen weiterhin korrekt funktionieren. Dies ermöglicht eine schnelle Validierung der Software nach jeder Änderung und trägt dazu bei, potenzielle Probleme frühzeitig zu erkennen.

Die Realität ist…

Uns ist bewusst, dass agile Testing nicht einfach ist. Vor allem der Umstieg von einem sequentiellen Entwicklungsprozess auf kontinuierliche Lieferung und Integration stellt viele Unternehmen vor großen Herausforderungen. Diese kennen wir. Deswegen entwickeln wir zusammen mit Kunden erfolgreiche Strategien für die Implementierung. Der Kunde hat ein Problem und wir kaiserzentrierte passende Lösungen.

Links

• What Silicon Valley Needs - Interview mit Jeff Sutherland (Testing soll vor der Review abgeschlossen sein)

Bilder und sonstige Dankeschöns!

• Titelbild: Fotosiora-photography-hgFY1mZY-Y0-unsplash.jpg von Siora Photography auf Unsplash