In vielen Projekten werden Arbeitspakete horizontal geschnitten. Das bedeutet, dass zuerst die Datenbank gebaut wird, dann ein erster Wurf aller Eingabemasken, aber noch ohne Logik, Fehlerbehandlung etc. Dann kommen nach und nach die Funktionen dazu. Das bedeutet, dass in der ersten Version nur viele Datenbanktabellen kommen. Als Tester kann man damit wenig anfangen. In der nächsten Version kommen dann zwar viele Masken, aber mehr als öffnen und anschauen kann man sie noch nicht. Auch da ist als Tester wenig testbar. Die ersten Iterationen hat man also als Tester wenig zu tun. Erst am Ende des Projektes werden dann alle Masken auf einmal fertig und man kann testen. Sowohl anforderungsbasierte als auch explorative Tests sind jetzt erst sinnvoll möglich. Als Tester hat man nun plötzlich einen Riesenberg an Testarbeit vor sich. Oft reicht die Zeit nicht mehr und das Produkt geht schlecht geprüft zum Kunden. In solchen Projekten wird zwar iterativ gearbeitet, vielfach werden diese Iterationen auch „Sprints“ genannt. Agil ist das aber nicht. Eine echte Zusammenarbeit zwischen Entwicklung und Test finden nicht statt, es wird wie im Wasserfall erst am Ende etwas geliefert, das Wert für den Kunden hat und die Qualität bleibt auf der Strecke.
Agil bedeutet, die Arbeit vertikal zu schneiden, das heißt, sie so aufzuteilen, dass in jedem Sprint wenige Themen begonnen werden, die aber vollständig fertiggemacht und getestet werden. Anstatt also im ersten Sprint für alle Objekte die Datenbanktabellen anzulegen, wird nur ein Objekt behandelt. Für dieses werden aber Datenbank, Business Logik und Masken fertiggestellt und können getestet werden. Im nächsten Sprint kommt dann das nächste Objekt dazu. Die Testarbeit teilt sich so gleichmäßig auf das gesamte Projekt auf, die Qualität ist von Anfang an hoch.
Echte Agilität ist also nicht bloß „Sprints zu machen“, sondern lieber weniger liefern und das dafür fertig und in hoher Qualität. Alles andere ist Wasserfall.
