Oft wird funktionale Testautomatisierung (UI-Testautomatisierung, REST-Testautomatisierung) im nächsten Sprint erstellt, nachdem das Feature fertiggestellt und manchmal sogar für die Produktion freigegeben wurde. Der Grund dafür ist, dass viele glauben, eine Funktion muss vollständig implementiert sein, bevor die Testautomatisierung erstellt wird. Ein weiterer Grund ist, dass im aktuellen Sprint nicht genügend Zeit zur Verfügung steht und die Erstellung von Automatisierung zum nächsten verschoben wird.

Dies hat mehrere Nachteile:

• Das Team hat sich weiterentwickelt und arbeitet bereits an anderen Features, die dazu führen, dass
  • die Motivation sinkt
  • der Support sinkt
  • das Know-How sinkt
    wenn es darum geht Testautomation für Features des vorherigen Sprints zu erstellen.

• Keine Entwicklung mit Blick auf die Testautomatisierung: Die Testautomatisierung ist vom eigentlichen Entwicklungsprozess entkoppelt, so dass sich die Entwickler nicht weiter darum kümmern. Daher kann es vorkommen, dass das implementierte Feature nicht effizient getestet werden kann und der Entwickler bereits ein anderes Feature implementiert, das nicht implementiert werden muss.
• Die Automatisierung wird unter aktuelleren Aufgaben leiden - da das Feature Teil des vorherigen Sprint-Backlogs war, sind im aktuellen Sprint sicherlich wichtigere Aufgaben als das Erstellen einer Testautomatisierung für Features früherer Sprints. Dies wird noch schlimmer, wenn die Automatisierung nicht mit der Entwicklungsgeschwindigkeit mithalten kann.
• Die Story ist noch nicht fertig - Eine Story kann als erledigt betrachtet werden, wenn auch Tests durchgeführt werden. Dies ist nur der Fall, wenn die Automatisierung erstellt wurde und stabil ist. Wenn nicht, ist die Geschichte zur Hälfte fertig und sollte nicht geschlossen oder veröffentlicht werden. Wenn die Story immer noch veröffentlicht wird, schwächt sie die Bedeutung der Testautomatisierung.
• Automatisierung nur für die Regression, nicht für die Progressionsprüfung: Wenn die Testautomatisierung richtig durchgeführt wird, kann sie auch für die Progressionsprüfung im aktuellen Sprint verwendet werden. Durch die Automatisierung der am häufigsten verwendeten Pfade (Happy Path, ...) für ein Feature kann das Testen bereits mithilfe der Automatisierung durchgeführt werden. Dies ist besonders nützlich, wenn sich andere Teile der Funktion (z. B. Fehler- und Ausnahmebehandlung) noch in der Entwicklung befinden und Auswirkungen auf die allgemeinen Pfade haben können.

Warum Testautomation für den aktuellen Sprint funktioniert?

Normalerweise beginnt die Entwicklung eines Features mit der Implementierung des glücklichen Pfads. Der Entwickler versucht daher, die erforderliche Funktionalität so schnell wie möglich bereitzustellen, ohne viel Fehler und Ausnahmen zu behandeln. Dies dauert normalerweise 20 bis 30% der Gesamtzeit, die zum Abschluss der Implementierung eines Features erforderlich ist. Gleiches gilt für Schnittstellen, Batches und alle anderen Implementierungen. Sobald der glückliche Pfad fertig ist, kann die Testautomatisierung erstellt werden. Es bleibt also mehr Zeit, die Automatisierung im aktuellen Sprint zu erstellen. Das nächste Diagramm visualisiert die Zeitleiste eines Sprints in Bezug auf die Featureentwicklung:

Das Diagramm zeigt die Verbindung zwischen Feature-Entwicklung und Feature-Test. Während der glückliche Weg implementiert ist, können Tester mit der Testvorbereitung beginnen (z. B. Vorbereitung der Testumgebung, Testdaten, Testfall). Sobald der glückliche Pfad fertig ist und für Acceptance bereitgestellt wurde, können Tester mit der Testautomatisierung beginnen. Der Entwickler muss mit der Fehlerbehandlung und Sonderfällen fortfahren. Nur ein Teil dieser Fälle sollte automatisiert werden. Dies ist normalerweise auf der Grundlage der Happy Path Test-Automatisierung sehr schnell möglich. Sobald die Feature-Implementierung abgeschlossen ist, sollte auch die Automatisierung durchgeführt werden, und die Tester können sich auf explorative Tests konzentrieren.

Wenn der Sprint zum richtigen Zeitpunkt läuft und alles stimmt, sollte dieser Ansatz gut funktionieren. Hier sind einige bewährte Methoden, um dies zu ermöglichen:

• Entwickeln mit dem Testing im Hinterkopf
• Verwenden Sie stabile IDs in der Benutzeroberfläche
• Schnittstellen frühzeitig stabilisieren
• Automatisierung frühzeitig in die Delivery-Pipeline integrieren
• Die Automatisierung ist Teil der Definition von done und es wird keine Funktion ohne ausreichende Testautomatisierung implementiert

Die Vorteile liegen auf der Hand:

• Testen ist Teil des Sprints. Die Entwickler müssen sich darum kümmern.
• Durch das Timing werden Sprints weniger überbucht und die Entwicklungsqualität steigt.
• Die Testautomatisierung ist immer auf dem neuesten Stand.
• Die Geschwindigkeit eines Teams wird stabil - keine Verlangsamung aufgrund technischer Schulden.
• Jeder wird dabei helfen, die Testautomatisierung abzuschließen, da sonst die Funktion nicht ausgeführt und nicht veröffentlicht wird.