In meinen Projekten höre ich oft Sätze wie „Unser Testing-Team macht auch Scrum, also machen wir agiles Testen“ oder „Wir testen in den Sprints, also machen wir agiles Testen. Und vor dem Release gibt es noch einen Testing-Sprint für die Integrationstests“ oder „Wir testen sprintversetzt – was in einem Sprint entwickelt wurde, testen wir im nächsten“ usw.Solche und noch viel mehr ähnliche Sätze zeigen mir, wie sehr „agiles Testen“ missverstanden wird. Alle erwähnten Aussagen zeigen mir nur: Es wird weiterhin nach dem Wasserfall entwickelt – nur in kürzeren Iterationen, mehr nicht. Kein agiles Entwickeln und schon gar nicht agiles Testen. Denn was ist „agil“ per Definition?
„Lieferung funktionierender Software in kurzen Iterationen und in Inkrementen.“
Wie aber soll man sicherstellen, dass die Software funktioniert, wenn sie nicht innerhalb einer Iteration getestet wird? Und zwar komplett. Nicht nur ein bisschen, ohne Integrationstests am Ende des Releases, ohne sprintversetzte Tests, sondern alles findet im Sprint statt, sodass am Ende des Sprints ein Stück Software potenziell an den Kunden geliefert werden kann.
Wir wissen, dass das ganze Entwicklungsteam für die Qualität des Produkts verantwortlich ist. Wenn nur die Tester testen, kann von gemeinsamer Verantwortung nicht die Rede sein. Natürlich braucht es weiterhin die Tester im Team. Sie bringen wertvolles Know-how mit, auf das nicht verzichtet werden kann. Dennoch können und sollten alle Teammitglieder ihren Beitrag zur Qualität des Produkts leisten, zum Beispiel so:
Mit anderen Worten: Agiles Testen ist die Gesamtsumme aller Tätigkeiten, die dafür sorgen, dass am Ende jedes Sprints die gelieferten Funktionalitäten funktionieren und vom Kunden potenziell sofort genutzt werden können.Foto: CC0 Creative Commons, testbytes - pixabay