Im Februar 1986 veröffentlichen Hirotaka Takeuchi und Ikujiro Nonaka ihren Artikel „New New Product Development Game“ im Harvard Business Review. Darin zeigen sie anhand von Fallstudien die Vorteile holistischer Entwicklungsansätze auf und ziehen dabei die Analogie zu Rugby (Rugby Approach) und damit zu SCRUM. Als die sechs Charakteristika des Managements eines neuen Produkt-Entwicklungsprozesses sehen die Autoren dabei: Built-in instability, Self-organizing project teams, Overlapping development phases, Multilearning, Subtle control und Organizational transfer of learning.

Eine der ersten Definitionen von SCRUM findet sich 1990 im Buch „Wicked Problems, Righteous Solutions: A Catolog of Modern Engineering Paradigms“ von Peter DeGrace und Leslie Hulet Stahl.

Zehn Jahre später, im Juli 2000, veröffentlicht Martin Fowler seinen Artikel „The New Methodology“, in welchem er die Entwicklung agiler Ansätze in den 90er Jahren zusammenfasst. Diese Ansätze sind eine Gegenreaktion zu den oft mit Dokumentationen und Prozessen überladenen und als zu bürokratisch und unflexibel erlebten Engineering Methoden der 80er und 90er Jahre. Der Unterschied zwischen agilen und traditionellen Methoden zeigt sich lt. Fowler jedoch nicht primär in Umfang und Form der Dokumentation, sondern darin, dass agile Methoden eher adaptiv denn vorhersagbar sind und für den Erfolg eines Vorhabens die Mitarbeiter bzw. das Team und eine funktionierende Kommunikation mehr beitragen als Prozesse und Regelungen.

Im Februar 2001 schließlich unterschreiben in Utah 17 Softwareexperten das „Agile Manifest“ – quasi die „10 Gebote“ der agilen Welt, bestehend aus 4 Werthaltungen und 12 Prinzipien. In diesen Prinzipien werden insbesondere die integrative Zusammenarbeit mit den Auftraggebern und Kunden sowie das primäre Ziel einer lauffähigen und auch verwendbaren Software in den Vordergrund gestellt.

All diesen Arbeiten ist gemeinsam, dass diese grundlegende Prinzipien für die agile Softwareentwicklung neu definieren, aber nicht im Detail auf konkrete Software Engineering Disziplinen eingehen. Mehr oder weniger greifbar erfolgt dies in den Definitionen einzelner agiler Methoden, wie eXtreme Programming, SCRUM, Test Driven Development, etc. Auch waren es in der Vergangenheit insbesondere Softwareentwickler, die die „Agile Community“ vorangetrieben haben. Diese Tatsache ist mit ein Grund dafür, dass die Aufgaben und die Rolle des Software-Testers in den agilen Methoden und Projekten oftmals nicht oder nur unklar definiert sind. Dazu tragen auch falsch interpretierbare Terminologien bei: Spricht SCRUM zum Beispiel von einem interdisziplinären Entwicklungsteam, meinen manche, das Team besteht nur mehr aus Entwicklern – im Sinne von Programmierern -, die alles machen. Andere wiederum glauben, dass im Test Driven Development mit der Erstellung eines automatisierten Unit Test-Sets die Testaufgaben in der Entwicklung hinlänglich erfüllt sind und der Rest in der Verantwortung des Anwenders im User Acceptance Test liegt.

Nicht zuletzt deshalb etablierte sich in den vergangen Jahren immer mehr der Begriff des „Agile Testing“. In der Literatur, auf vielen nationalen und internationalen Konferenzen und in erfolgreichen, agilen Projekten wird die große Bedeutung und die wesentliche Rolle des Software-Tests beim Erreichen des primären Ziels von agilen Projekten, nämlich die Auslieferung von funktionstüchtiger und somit auch qualitativ hochwertiger Software, offenbar.

Besonders die folgenden vorgestellten Aspekte werden dabei als Erfolgsfaktoren bzw. Best Practices gesehen:

Der Software-Tester als Bestandteil eines interdisziplinären Teams

Bereits Martin Fowler hatte in seinem Essay darauf hingewiesen, dass es über den Software-Entwickler hinaus noch viele weitere Beteiligte im Software-Entwicklungsprozess gibt, unter anderem die Tester. Diese sind ebenso Bestandteil des interdisziplinären Teams wie Programmierer, Architekten, Analytiker etc. Die Beteiligten müssen interdisziplinär denken und übernehmen verstärkt Arbeiten abseits ihrer zentralen Aufgabenstellung. Dieser Wandel im Denken ist auch für den Tester eine Herausforderung. In agilen Teams kann der Entwickler Testaufgaben übernehmen und der Tester Entwicklungsaufgaben – je nach Maßgabe und Skill-Entwicklung. Anzunehmen, dass dies so einfach möglich ist, wäre jedoch ein Fehler: Weder ist ein gelernter Entwickler auf Knopfdruck ein guter Tester noch sind Tester automatisch mit entsprechender Programmiererfahrung ausgestattet. Es wäre außerdem fatal, nicht alle Software Engineering Disziplinen in Exzellenz im Team vertreten zu haben. Gerade agile Methoden verlangen darin höchste Expertise und Erfahrung: Analytiker, die die Anforderungen des Anwenders klar verstehen und gesamtheitlich erfassen können; erfahrene Architekten, die eine Architektur entwerfen, die durch laufende Änderungen nicht in ein Chaos führt; Programmierer, die den Code so schreiben, dass für ihn dasselbe gilt, wie für die Architektur und die konsequent Unit Tests definieren, die mehr prüfen als nur die Existenz von Klassen und deren Methoden; und professionelle Tester, die ihre Testansätze und Testmethoden jeweils an die konkreten und sich immer wieder ändernden Aufgabenstellungen anpassen und den Automatisierungsgrad im Systemtest schon während der Entwicklung vorantreiben.

Unit Test und User Acceptance sind kein Ersatz für den System- und Systemintegrationstest

Der Unit Test, der im Normalfall durch den Entwickler definiert und – möglichst vollautomatisiert -  durchgeführt wird, adressiert in der Regel die Funktionstüchtigkeit einzelner Klassen oder deren Methoden. Durch den „write the test first“-Ansatz agiler Methoden werden bereits zu einem frühen Zeitpunkt die Spezifikationen inhaltlich präzisiert und eine grundlegende Qualitätssicherung der einzelnen Softwarekomponenten initiiert. Dieser Ansatz verlangt eine sehr hohe Konsequenz der Entwickler bei der Erstellung der Unit Tests. Diese sollen ja nicht nur die Existenz z.B. einer bestimmten Methode nachweisen, sondern auch die Vollständigkeit und Korrektheit der Umsetzung gegebener Anforderungen. Dafür ist ein methodischer Testfallentwurf notwendig, der zu umfangreicheren Unit-Tests führt. In der Praxis zeigt sich oftmals, dass der inhaltliche Abdeckungsgrad der Unit-Tests stark zu wünschen übrig lässt.

Doch selbst wenn dieser gegeben ist, ist damit noch lange nicht die Überprüfung des gesamtheitlichen Zusammenspiels aller Softwarekomponenten erfolgt. Bei der Übernahme in den Akzeptanztest erwartet der Anwender ein bereits getestetes und voll funktionstüchtiges System. Daher ist auch im agilen Testansatz sicherzustellen, dass alle Stories, Use Cases, die Schnittstellen zu Drittsystemen und deren komplexes Zusammenspiel in Rahmen von End to End Test vor Übergabe an den Akzeptanztest getestet und entsprechend vorgegebener Kriterien freigegeben wurden.

Erfahrungsberichte von Unternehmen, die agile Verfahren einsetzen, zeigen dafür unterschiedliche Ansätze: Längere Sprints, in denen das Testteam parallel zur Entwicklung die Tests für den „Selected Product Backlog“ vorbereitet und durchführt (das Ende des Sprints dient nur noch der Fehlerbehebung und Retest); kürzere Sprints, wobei die Ergebnisse eines Sprints zeitversetzt im zweiten Sprint getestet werden; oder sogar ein „Test-SCRUM-Projekt“ parallel zum „Entwicklungs-SCRUM-Projekt“ wobei die Synchronisation in „scrum of scrum“ Meetings erfolgt.

Wie bei allen Vorgehensmodellen wird es also je nach Voraussetzungen und Rahmenbedingungen auch unterschiedliche Ausprägungen dafür geben, wie die Testaktivitäten organisiert und optimiert werden. Wie bereits Martin Fowler ausgeführt hatte, ist der „Self-Adaptive Process“ ein wichtiger Wesenszug agiler Ansätze.

Besondere Herausforderungen für den Agilen Tester

Die besonderen Herausforderungen für den Software-Tester ergeben sich aus einigen Grundprinzipien agiler Vorgehensweisen:

„Working software is the primary measure of progress“, so heißt es in einem der zwölf Prinzipien des Agilen Manifests. Zum Ende jeden Sprints, mit jeder Release, muss die Software funktionstüchtig und korrekt sein: Insbesondere bei sehr kurzen Zyklen ist dies schwer zu gewährleisten, wenn gleichzeitig bis zum letzten Tag entwickelt wird. Wie in traditionellen Vorgehensmodellen, in denen die Testphase oft nur als Puffer für evtl. Projektverzögerungen gesehen wurde, muss sich der Test auch in agilen Projekten etablieren und behaupten. Die Planung der Sprints bzw. der Releases muss gewährleisten, dass alle notwendigen Testaktivitäten stattfinden können. Hier gilt es, je nach Kritikalität flexibel jene Testmethoden einzusetzen, die für die Gewährleistung der Zielerreichung ausreichend sind. Das kann in einem Fall ein strukturierter Testfallentwurf, im anderen Fall vielleicht ein Explorativer Test sein.

„Welcome changing requirements, even late in development“, lautet ein anderes Prinzip. In eXtreme Programming ist das laufende Refactoring des Codes ein wesentlicher methodischer Bestandteil. Für den Test bedeutet aber jede fachliche oder technische Modifikation nicht nur den Test jener Änderung, sondern auch einen ausreichenden Regressionstest bereits durchgeführter Prüfungen. Agile Methoden sehen dafür aber kaum Zeit vor. Daher scheint die Automatisierung des funktionalen Regressionstests einerseits ein Muss für agile Projekte zu sein. Andererseits ist diese eben durch die ständigen, potentiellen Änderungen und Erweiterungen schwer und nur mit entsprechendem Aufwand zu realisieren. Wie bereits oben angeführt, handelt es sich dabei nicht einfach nur um den Ausbau der Unit Tests.

Das neue Rollenverständnis des Testers im interdisziplinären Team stellt ebenfalls eine Herausforderung dar. Dies trifft insbesondere auf den Testmanager zu. Als Funktion ist er nicht mehr definiert, sehr wohl aber als Rolle mit konkreten Aufgaben. Es geht für ihn nicht mehr darum, zu Beginn eines Testprojekts ein Testkonzept und einen Testplan zu erarbeiten, sondern darum, laufend und immer wieder die gewählten Ansätze zu reflektieren und anzupassen, sich um alle Belange der Testorganisation zu kümmern und auch selbst als „Chef-Tester“ zu fungieren – ähnlich seinem Pendant, dem „Chef-Entwickler“ bzw. Architekten im Team.

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

Um dieses oberste Agile Prinzip gewährleisten zu können, also dem Kunden auch wirklich „wertvolle“ Software zu liefern, ist eine ausreichende Qualitätssicherung der gelieferten Produkte notwendig. Dies erfordert den Einsatz entsprechender Testmethoden und Werkzeuge und das Mitwirken von Teammitgliedern mit hoher Expertise im professionellen Software-Test. Diesbezüglich gibt es keinen Unterschied zwischen einem traditionellen und einem agilen Vorgehen.

Die Anforderungen an den Tester und Testmanager haben sich durch agile Vorgehen geändert, die Verantwortung für erstklassige Qualität hochwertiger Software jedoch nicht.