Wenn wir über traditionelles Testen sprechen, meinen wir das V-Modell, das in Wasserfall-Projekten verwendet wird. Wir betreiben Requirements Engineering, schreiben Features für unsere Software nieder, brechen diese dann herunter und schreiben Stories, die anschliessend den Entwicklern zur Umsetzung übergeben werden. Der Entwickler setzt dies in Code um und schreibt dann Unit Tests und Integrationstests.
Wenn er fertig ist, übergibt er die Story an Tester, die sie testen. Nachdem alle Tests entwickelt wurden, werden die Features getestet.
Das Problem bei diesem traditionellen Ansatz ist das verzögerte Feedback. Nach dem Schreiben der Features dauert es 3 Monate oder länger, bis wir Feedback erhalten.
Beim agilen Testen verschieben wir das gesamte Testen nach links. Wir verwenden BDD (Behaviour-Driven Development), um die Akzeptanzkriterien bereits beim Schreiben eines Features zu definieren. Wir brechen das Feature in User Stories herunter, bei denen die Akzeptanzkriterien ebenfalls mit BDD geschrieben werden. Dadurch erhalten wir ausführbare Spezifikationen. Der Entwickler kann dann zuerst die als Akzeptanzkriterien in der User Story spezifizierten Tests verwenden, bevor er mit der Implementierung der Funktionalität beginnt.
Auf diese Weise haben wir Tests auf Story- und Feature-Ebene von Anfang an. In unserer Continuous-Delivery-Pipeline können wir die Tests ausführen, die den Entwicklern bestätigen, dass nichts kaputt gegangen ist. Das führt zu einer schnelleren Time-to-Market.