Im Winter 2001 wurde auf einer entlegenen Skihütte im Staate Utah von einer kleinen, verschworenen Clique bekannter Software-Entwickler zu einer Revolution in der Software-Welt aufgerufen. Sie erschufen das Agile Manifest. Mit diesem Manifest legte die Gruppe fest, was sie ohnehin schon mit Extreme Programmierung praktizierten. Aber mit der schriftlichen Formulierung gelang ihnen ein publizistischer Coup, mit dem sie weltweit Aufmerksamkeit für ihr Anliegen gewannen. Die Entwicklungsexperten, die sich dort versammelten, hatten es satt, sich von starren Prozessregeln, unsinnigen bürokratischen Richtlinien und weltfremden Vorgehensweisen der damaligen Software-Engineering-Disziplin gängeln zu lassen. Sie erkannten, dass das monotone Arbeiten nach Vorschrift in der neuen schnelllebigen Zeit überholt war. Sie wollten sich von den Fesseln der Projektbürokratie befreien, um zusammen mit den Anwendern Software nach Bedarf zu entwickeln. An die Stelle der bisher schwerfälligen, phasenorientierten, dokumentengesteuerten Software-Entwicklung sollte eine flexible, menschengesteuerte Entwicklung mit kleinen, überschaubaren Schritten treten. Die agile Software-Entwicklung sollte die Vorgehensweise des neuen Jahrhunderts sein.

Im Vordergrund der agilen Entwicklung steht nicht das Projekt, sondern das Produkt. Da Software-Entwicklung immer mehr zu einer Expedition ins Ungewisse wurde, sollte das Produkt Stück für Stück in kleinen Inkrementen entstehen. Statt lange Absichtserklärungen bzw. Anforderungsdokumente zu schreiben, über Dinge, über die man zu dem Zeitpunkt gar nicht Bescheid wissen konnte, sollte man lieber gleich etwas programmieren, um eine schnelle Rückkopplung von dem künftigen Benutzer zu bekommen. Es soll nicht mehr Monate oder gar Jahre dauern, bis sich herausstellt, dass sich das Projekt auf einem Irrweg befindet oder das Projektteam überfordert ist. Dies sollte sich schon nach wenigen Wochen erweisen.

Das Grundprinzip der agilen Entwicklung ist also die inkrementelle Lieferung. Ein Software-System soll stückweise fertiggestellt werden. Damit hat der Benutzervertreter im Team die Möglichkeit mitzuwirken. Nach jeder neuen Auslieferung kann er das ausgelieferte Zwischenprodukt mit seinen Vorstellungen vergleichen. Der Test ist dadurch in das Verfahren eingebaut. Die Software wird von Anfang an dauernd getestet. Ob da ein Tester mit im Spiel ist, wurde zunächst offengelassen. Die Verfasser des agilen Manifests waren gegen eine strenge Arbeitsteilung. Die Aufteilung in Analytiker, Designer, Entwickler, Tester und Manager war ihnen zu künstlich und verursachte zu viele Reibungsverluste. Natürlich soll das Projektteam diese Fähigkeiten besitzen, aber die Rollen innerhalb des Teams sollten austauschbar sein. Das Entwicklungsteam soll als Ganzes für alles verantwortlich sein. Erst durch die Beiträge von Crispin und Gregory hat sich die Rolle des Testers im Team herausgestellt. Die beiden haben sich dafür eingesetzt, dass sich jemand im Team um die Belange der Qualität kümmert.

Software-Entwicklung verlangt sowohl Kreativität als auch Disziplin. Gegen Ende des letzten Jahrhunderts haben die Befürworter von Ordnung und Disziplin die Oberhand gehabt und mit ihren strengen Prozessen und Qualitätssicherungsmaßnahmen die Kreativität der Entwickler vereitelt. Wenn übertrieben wird, kehrt sich alles ins Gegenteil um. Mit dem Qualitätsmanagement wurde zu viel des Guten getan. Die Gegenreaktion war die agile Bewegung, die darauf ausgerichtet war, mehr Spontaneität und Kreativität in die Software-Entwicklung zurückzubringen. Dies ist durchaus zu begrüßen, aber auch hiermit darf nicht übertrieben werden. Man braucht einen Gegenpol zu der sprudelnden Kreativität der Benutzer und Entwickler. Dieser Gegenpol ist der Tester im Team.

In jedes Entwicklungsteam gehört mindestens ein Tester, um die Belange der Qualität zu vertreten. Der Tester oder die Testerin sorgt dafür, dass das entstehende Produkt sauber bleibt und die vereinbarten Qualitätskriterien erfüllt. In dem Drang, schneller voranzukommen, geraten die nichtfunktionalen Qualitätsanforderungen gegenüber den funktionalen Anforderungen allzu leicht ins Hintertreffen. Es ist der Job des Testers, dafür zu sorgen, dass ein Gleichgewicht zwischen Produktivität und Qualität bewahrt wird. Der Tester ist sozusagen der gute Geist, der das Team davon abhält, Fortschritt auf Kosten der Qualität zu erringen. In jedem Release soll nicht nur mehr Funktionalität, sondern auch mehr Qualität angestrebt werden. Der Code soll regelmäßig bereinigt bzw. refaktoriert, nachdokumentiert und von Mängeln befreit werden. Dass dies tatsächlich geschieht, ist die Aufgabe des Testers.

Natürlich hat die agile Projektorganisation auch Folgen für den Test und die Qualitätssicherung. Die Verantwortlichen für die Qualitätssicherung sitzen nicht mehr in einer entfernten Dienststelle, von wo aus sie die Projekte überwachen, die Projektergebnisse zwischen den Phasen kontrollieren und in der letzten Phase das Produkt durchtesten. Sie sind in den Entwicklungsteams fest integriert, wo sie ständig prüfen und testen. Es obliegt ihnen, auf Mängel in der Architektur sowie im Code hinzuweisen und Fehler im Verhalten des Systems aufzudecken. Ihre Rolle ist jedoch nicht mehr die des lästigen Kontrolleurs, sondern vielmehr die des Freund und Helfers. Sie weisen auf die Probleme hin und helfen den Entwicklern, die Qualität ihrer Software auf den erforderlichen Stand zu bringen. Im Gegensatz zu dem, was manche behaupten – nämlich, dass Tester in agilen Projekten nicht mehr nötig sind –, ist ihre Rolle wichtiger denn je. Ohne ihren Beitrag wachsen die technischen Schulden und diese bringen das Projekt früher oder später zum Stillstand.

Das vorliegende Buch beschreibt den agilen Test in zehn Kapiteln. Das erste Kapitel schildert den kulturellen Wandel, den die agile Entwicklung mit sich gebracht hat. Mit dem agilen Manifest wurden die Weichen für eine Neuordnung der IT-Projektlandschaft gesetzt. Es soll nicht mehr starr nach Phasenkonzept, sondern flexibel in kleinen Iterationen entwickelt werden. Nach jeder Iteration soll ein lauffähiges Teilprodukt vorzuweisen sein. Damit werden Lösungswege erforscht und Probleme früh erkannt. Die Rolle der Qualitätssicherung wandelt sich. Statt als externe Instanz auf die Projekte von außen zu wirken, sind die Tester im Projekt eingebettet, um ihre Tests sofort vor Ort als Begleiter der Entwicklung durchzuführen. Natürlich müssen die Anwenderbetriebe ihre Managementstrukturen entsprechend anpassen: Statt abseits auf ein Endergebnis zu warten, sind die Anwender aufgefordert, im Projekt aktiv mitzumachen und die Entwicklung über ihre Anforderungen, sprich „Stories“, zu steuern. Auf der Entwicklungsseite arbeiten sie mit den Entwicklern zusammen, um die gewünschte Funktionalität zu analysieren und zu spezifizieren. Auf der Testseite arbeiten sie mit den Testern zusammen, um zu sichern, dass das Produkt ihren Erwartungen entspricht.

Letztendlich müssen sich alle umstellen – Entwickler, Tester und Anwender –, um das gemeinsame Ziel zu erreichen. Manch traditionelle Rolle fällt dabei weg wie die des Projektleiters und des Testmanagers. Dafür gibt es neue Rollen wie die des Scrum Masters und des Teamtesters. Das Projektmanagement im klassischen Sinne findet nicht mehr statt. Jedes Team managt sich selbst. Die IT-Welt ändert sich und mit ihr die Art und Weise, wie Menschen Software entwickeln. Es gilt also, diesem neuen Zustand gerecht zu werden. Der Weg dazu wird hier im ersten Kapitel geschildert.

Im zweiten Kapitel über agile Vorgehensmodelle gehen die Autoren auf die Rolle der Qualitätssicherung in einem agilen Entwicklungsprojekt ein. Dabei scheuen sie sich nicht, die verschiedenen Zielkonflikte, z. B. zwischen Qualität und Termintreue, zwischen Qualität und Budget und zwischen Qualität und Funktionalität objektiv zu betrachten. Die Versöhnung dieser Zielkonflikte ist eine Herausforderung des agilen Tests.

Im Gegensatz zur landläufigen Meinung, dass in den agilen Projekten weniger getestet werden muss, wird hier gefordert, noch mehr zu testen. Test-Driven Development (TDD) soll nicht nur für den Unit Test, sondern auch für den Integrations- und Systemtest gelten, nach der Devise: erst die Testfälle, dann der Code. Hier heißt es: erst die Testspezifikation, dann die Implementierung. Dabei spielt die Testautomation eine entscheidende Rolle. Erst wenn der Test automatisiert ist, kann in der erforderlichen Geschwindigkeit die erforderliche Qualität erreicht werden. Das ganze Team soll sich an dem Automatisierungsprozess beteiligen, denn der Tester allein kann es nicht schaffen. Er braucht die Unterstützung der Entwickler, denn er hat auch andere Aufgaben zu erledigen. Neben dem Test wird auch die Durchführung von Audits zu bestimmten Zeitpunkten in der Entstehung des Software-Produkts gefordert. Die Audits zielen darauf hin, Schwachstellen und Missstände in der Software zu enthüllen. Der Zeitpunkt dafür ergibt sich nach jedem Sprint in einem Scrum-Projekt. Aufgrund der Ergebnisse der Audits können die Prioritäten für den nächsten Sprint gesetzt werden. Diese kurzen Audits bzw. Momentaufnahmen der Produktqualität können durch QS-Experten von außen in Zusammenarbeit mit dem Team durchgeführt werden. Der Zweck ist nicht zu sehr, das Projekt durch Kritik aufzuhalten, sondern dem Team zu helfen, Risiken rechtzeitig zu erkennen.

Zusätzlich zum Scrum-Prozess behandelt das zweite Kapitel auch Kanban und den schlanken Software-Entwicklungsprozess (Lean Software). Der Leser bekommt etliche Hinweise, wie Qualitätssicherung in diesen Verfahren...