In der jüngeren Vergangenheit habe ich an verschiedenen Stellen über Test Driven Development (TDD), Behaviour Driven Development (BDD) und andere qualitätssichernde Maßnahmen in agilen Projekten diskutiert. Früher oder später kamen wir dann oft zu einer spannenden Fragestellung: Was machen eigentlich die – in größeren Unternehmen meist vorhandenen – klassischen Tester in agilen Projekten?
Einige Testarten werden in agilen Projekten von den Entwicklern implementiert. Sie schreiben z.B. Unit Tests oder Akzeptanztests und folgen damit dem Ansatz „Teste früh, teste häufig“. Diese Tests entstehen mit der Implementierung der jewiligen Features, also früh. Und sie sind automatisiert ausführbar, werden idealerweise vom Continuous-Integration-System häufig durchgeführt. Und was macht der Tester? Wird er damit überflüssig?
Nein, wird er nicht! Hat der Tester seinen Schwerpunkt auf der technischen Ebene, wird sich seine Rolle wandeln. Er kann z.B. zum Coach für die Entwickler werden und ihnen dabei helfen, Tests effizient zu schreiben und Best Practices zu entwickeln. Hat er seinen Schwerpunkt auf der fachlichen Ebene, wird er mehr Zeit für die Fachlichkeit bekommen. Hat er bisher Testpläne und -spezifikationen verfasst und implementiert, so kann er sich nun auf die Erstellung zusammen mit dem Fachbereich konzentrieren, da die Implementierung im Rahmen von BDD durch den Entwickler erfolgt. Die Spezifikation mag in einem anderen Format erstellt werden, ist aber nach wie vor erforderlich und kann meiner Erfahrung nach nicht vom Fachbereich allein geleistet werden. Eine gute Testspezifikation berücksichtigt viele Sonderfälle und Ausnahmebedingungen, an die ein Tester als berufsbezogener Pessimist sofort denkt, wenn er sich ein Feature anschaut. Dem Fachbereich geht dies meist ab, da er sich eher Gedanken darüber macht, was das Feature können soll. Er möchte, dass das Feature funktioniert und denkt weniger darüber nach, was alles schief laufen kann.
Neu wird sein, dass die Testspezifikation sehr früh erfolgen muss, da die Entwickler diese bereits für die Implementierung benötigen – schließlich wollen sie die Tests zusammen mit dem produktiven Code entwickeln. Eine Erstellung der Testspezifikation nach der Implementierung ist also nicht möglich. Sinnvoll ist dies ohnehin nicht, da die Gefahr besteht, dass sie sich an der Implementierung orientiert, die nicht unbedingt dem entspricht, was der Fachbereich haben möchte.
Daneben gibt es auch noch andere Test-Maßnahmen, die auch in agilen Projekten nicht wegfallen und nicht sinnvoll von den Entwicklern übernommen werden können. Man denke z.B. nur an UI-Tests oder Lasttests. Der Tester wird meiner Meinung nach in agilen Projekten also alles andere als überflüssig. Seine Arbeitsweise wird sich ändern und er rückt näher an das Entwicklungsteam.
