Vor einiger Zeit nahm ich an einer Umfrage zum Thema Agiles Testen teil. Etwas überrascht war ich heute, als ich über Twitter von Andreas Simon erfuhr, dass die Ergebnisse veröffentlicht wurden. Davon ausgehend, dass ich die Benachrichtigung übersehen hatte, habe ich mir den Artikel dann heute zu Gemüte geführt. Als Tester weiß ich allerdings auch, dass ich keiner Statistik trauen sollte, die ich nicht selber gefälscht habe. Während die Autoren ein paar Interpretation der Daten in dem Artikel beschreiben, möchte ich im Folgenden meine eigene Sichtweise wiedergeben.

Die Befragung richtete sich mit drei unterschiedlichen Fragebögen an drei unterschiedliche Zielgruppen: Tester, Entwickler und Manager. Zu einem Großteil nahmen Teilnehmer aus der Gruppe Tester an der Umfrage teil. Anhand der Daten empfinden sich mehr Personen in agilen Projekten als Entwickler.

Interessant bei den Daten finde ich, dass 27 Prozent der Befragten angegeben haben, nach einem eigenen agilen Modell Software zu entwickeln. Ohne die konkreten Firmen zu kennen, will ich allerdings keine Bewertung abgeben.

Die Daten zeigen außerdem, was ich in meinem Kapitel über Agiles Testen in „How to reduce the cost of testing“. Die Verantwortung für Qualitätssichernde Maßnahmen in Agilen Team liegt im gesamten Team. Manager, Entwickler und Tester tragen gleicher Maßen Verantwortung für Qualität. Agile Prkatiken wie Pair Programming, TDD, ATDD und Continuous Integration geben dem Projekt nicht nur Transparenz, sondern auch ein verteiltes Qualitätbewußtsein.

Wo wir bei Praktiken aus der Agilen Softwareentwicklung sind, spiegeln diese Daten die Bedeutung für die Qualitätssicherung nicht wirklich wieder. Ich schließe hieraus eher, dass es an dem Zusammenspiel der Praktiken liegt. In eXtreme Programming Explained beschreibt Kent Beck auch das Zusammenspiel dieser Praktiken, James Shore und Shane Warden warnen in ihrem Buch The Art of Agile ebenfalls vor frühzeitiger Anpassung von Praktiken, bevor man nicht verstanden hat, wieso man den gesamten Mix benötigt.

In Frage stelle ich den Zusammenhang zwischen Testphasen und der Bedeutung für agile Projekte. Wie Elisabeth Hendrickson in ihrer Präsentation zu Agilem Testen erklärt, ist Testen keine Phase in agilen Projekten. Hilfreicher ist da das Modell der Testquadranten, das Brian Marick vor einiger Zeit beschrieben hat. Auch sind traditionelle Testpraktiken nicht äquivalent auf agile Projekte übertragbar.

Schade finde ich die Ergebnisse betreffend der Kundeneinbeziehung. Ich denke, dass agile Teams im deutschsprachigen Raum noch viel über Spezifikation mit Beispielen, ATDD und lebendige Dokumentation lernen können.

Sehr nachdenklich stimmt mich zudem das Ergebnis bezüglich Explorativem Testen. Die Autoren Andreas Spillner und Karin Vosseberg schließen im Artikel folgendes:

Freies Testen ohne Vorgaben und Ziele ist sehr beliebt.

Eine der frühen Lektionen, die ich als Tester gelernt habe, ist, dass ich meinen Auftraggeber kennen muss. Wenn es sich beim Explorativem Testen ohne Charta wirklich um „freies Testen ohne Vorgaben und Ziele“ handeln sollte, halte ich diese Art von Testen für eine unprofessionelle Zeitverschwendung. Beim besten Willen, Auftragsklärung gehört zum Testen dazu, wie Testdesign, Testdurchführung und Lernen.

Insgesamt unterstützen die Daten viele meiner Bauchgefühle. Sie helfen mir allerdings nur mäßig dabei, das zugrunde liegende Problem zu lösen. Bleibt einzig die Hoffnung, dass sich unser Berufsfeld in den kommenden Jahren von dem derzeitigen Mißstand erholen kann und zu einem respektablen Feld weiteretnwickelt.