Neuauflage Agile Testing

Agiles Testen beschreibt heute den Common Sense guter Testpraxis, nicht mehr den Gegenentwurf zu klassischen Methoden. Tester sind gleichwertige Mitglieder agiler Teams, verantwortlich für Qualität von Anfang an. Bewährte Testtechniken wie Äquivalenzklassen- oder Grenzwerttest bleiben dabei genauso gültig wie Testautomatisierung und die Integration von Fachbereichen und Betrieb.

Das Wichtigste in Kürze

• Agile Tester, die keine klassischen Testtechniken wie Äquivalenzklassentest oder Grenzwertanalyse beherrschen, machen einen grundlegenden Fehler, weil diese Methoden auch im agilen Umfeld vollständig anwendbar sind.
• DevOps wird in vielen Unternehmen falsch umgesetzt: Statt eine teamübergreifende Kultur zu schaffen, wird daraus einfach eine neue Abteilung, die genauso isoliert arbeitet wie früher die klassische Testabteilung.
• Wenn mehrere agile Teams unabhängig voneinander entwickeln, entsteht eine Lücke auf Systemebene, weil niemand prüft, ob die Teilergebnisse tatsächlich zusammenpassen.
• Selbstbewusstsein als Tester bedeutet nicht, mit dem erhobenen Zeigefinger auf Fehler hinzuweisen, sondern andere durch konkrete Techniken wie Entscheidungstabellen auf deren eigene blinden Flecken aufmerksam zu machen.

Warum Tester auch in agilen Projekten gebraucht werden

Tester verschwinden nicht, nur weil ein Team agil arbeitet. Genau dieser Irrtum stand am Anfang: In manchen Projekten hieß es plötzlich “Wir brauchen keine Tester mehr, weil wir jetzt agil arbeiten.” Dahinter steckte ein Missverständnis, vermutlich ein Übersetzungsfehler aus dem Englischen.

In agilen Büchern ist vom Development Team die Rede. Im deutschsprachigen Raum wird unter “Developer” oft der klassische Programmierer verstanden. Wenn ein agiles Team nur noch als Programmiererteam gelesen wird, fällt der Tester gedanklich weg.

Die Annahme, Entwickler erledigten das Testen einfach mit, hat sich nicht bewährt. Es gibt einzelne Lead Developer mit einem starken Qualitätsanspruch, doch das ist eher eine persönliche Eigenschaft als ein methodisches Vorgehen. Testkompetenz lässt sich damit nicht ersetzen.

Agil ist heute Common Sense, nicht mehr die Ausnahme

Agilität ist vom Sonderfall zum Standard geworden. Auf internationaler Ebene, etwa in der Arbeit des ISTQB, fällt es zunehmend schwer, eine Vorgehensweise eindeutig als “agil” oder “nicht agil” zu klassifizieren. Agil ist zum Oberbegriff für viele bewährte Praktiken geworden.

Im ISTQB Foundation Level wird deshalb nicht mehr zwischen agilem und nicht-agilem Testen unterschieden. Der Maßstab lautet stattdessen: gutes Testen gegen schlechtes Testen. Es geht um Good und Bad Practices, nicht mehr um ein Lager-Denken.

Der Begriff “Wasserfall” als Gegenpol war schon immer schief. In der Praxis liefen Projekte über Jahrzehnte iterativ, nicht in einem einzigen, nicht umkehrbaren Durchlauf. Verändert hat sich vor allem die Geschwindigkeit und der Umfang der einzelnen Iterationen, nicht das iterative Grundprinzip selbst.

Der Tester ist vollwertiges Mitglied des Teams, nicht Zaungast

Ein Tester gehört in agilen Projekten von Anfang an dazu, oder er gehört gar nicht dazu. Ein Mittelweg, bei dem man ein bisschen mitmachen, aber nicht mitreden darf, funktioniert nicht.

Vor zehn Jahren berichteten Testerinnen und Tester häufig, dass sie bei Sprint Planning und Planning Poker außen vor blieben. Die anderen planten, die Tester durften zuschauen. Diese Rolle hat sich gewandelt.

Der Tester gestaltet das Projekt heute von Beginn an mit und ist gleichwertiges Mitglied des Entwicklungsteams. Er ist nicht mehr derjenige, der am Schluss die Kohlen aus dem Feuer holen soll. Genau diese Emanzipation der Testrolle gehört zu den größten Verschiebungen der letzten zehn Jahre.

Warum Testtechniken auch im agilen Umfeld gelten

Agiles Testen macht klassisches Test-Handwerk nicht überflüssig. Wer sich als agiler Tester bezeichnet und Äquivalenzklassentest, Grenzwerttest oder Entscheidungstabellen nicht beherrscht, arbeitet schlechter, nicht moderner.

Auch explorativer Test ist kein freies Herumspielen. Session-based Testing wird bewusst aufgesetzt, mit klarem Ziel und unter Anwendung erlernter Techniken. Ingenieurmäßiges Vorgehen bleibt der Anspruch, auch wenn der Rahmen agil ist.

Was sich ändert, ist die Tiefe der Dokumentation. Ein einzelner Testfall wird heute selten so detailliert beschrieben wie früher. Arbeiten parallel Automatisierer am selben Fall, lohnt sich eine genauere Beschreibung trotzdem. Das Prinzip dahinter ist Lean: nur das tun, was nötig ist, um das Ziel bestmöglich zu erreichen.

Was sich in zehn Jahren agilem Testen verändert hat

Drei Verschiebungen prägen das agile Testen heute: höhere Geschwindigkeit, DevOps als Kulturthema und stark gestiegene technische Anforderungen an den Tester.

Der Druck, schnell auf Anforderungen zu reagieren und nah am Markt zu bleiben, ist deutlich gewachsen. Damit braucht es Testautomatisierung, die sich sauber in Continuous Integration einfügt. Die Werkzeuge agieren inzwischen auf hohem Niveau, müssen aber dynamischer werden.

DevOps hat das Testen stark beeinflusst, ist aber im Kern ein Kulturthema. In vielen Unternehmen wird DevOps an eine eigene Abteilung delegiert, ähnlich wie früher die Qualitätssicherung irgendwo im 17. Stock saß. Damit wird die Idee verfehlt, Menschen zusammenzubringen. Für Tester heißt DevOps vor allem: deutlich mehr Berührung mit dem Betrieb und mit nicht-funktionalen Aspekten.

Nicht-funktionale Qualität ist wichtiger geworden, allen voran Security. Der Tester muss heute breit aufgestellt sein, ergänzt um einige Spezialisten, die in einzelnen Themen in die Tiefe gehen.

Der Tester wird technischer

Das gefragte Profil verschiebt sich Richtung technischer Tester. Gemeint ist jemand, der API-Schnittstellen testen kann, mit Entwicklern und Architekten auf Augenhöhe spricht, sich in DevOps-Szenarien zurechtfindet und zumindest punktuell automatisiert.

Dieser Anspruch ergibt sich aus dem Vorgehen selbst. Niemand wartet mehr ein halbes Jahr auf eine fertige Applikation, die sich dann über die Oberfläche durchtesten lässt. Stattdessen müssen halbfertige Produkte in jedem Sprint getestet werden, oft über Schnittstellen und über das, was der Entwickler gerade bereitstellt.

Wer sichert die Integration komplexer Systeme?

Beim Sprung von einzelnen Applikationen zu integrierten Systemlandschaften entsteht eine Lücke. Eine kleine Applikation existiert selten für sich. Es gibt Umsysteme, komplexe Integrationen, und irgendwer muss das Funktionieren des Gesamtsystems absichern.

Das lässt sich am V-Modell veranschaulichen. Auf der linken, absteigenden Seite arbeiten die agilen Teams an einzelnen Komponenten. Beim Aufstieg auf der rechten Seite, der Integration, fehlt vielen Unternehmen heute genau die Instanz, die früher ein Testzentrum virtuell abgedeckt hat.

Skalierungsframeworks mit Value Streams adressieren das auf Epic-Ebene, lösen aber nicht automatisch die Frage, wer die Integration testet. In der Praxis entstehen dafür eigene agile Integrationstestteams. Deren Arbeit ist im Kern eine Entwicklungsaufgabe, nämlich viele Systeme zusammenzufügen, und genau dort fallen die Fehler auf, die einzelne Teams nie gesehen haben.

Qualität ist alle verantwortlich heißt oft niemand verantwortlich

Das agile Grundprinzip, dass jeder für Qualität verantwortlich ist, kippt ohne klare Rollen ins Gegenteil. Wenn alle verantwortlich sind, fühlt sich am Ende niemand zuständig.

Deshalb braucht es weiterhin jemanden, der den Überblick behält. Das Management interessiert sich nicht für die saubere Arbeit eines einzelnen Teams, sondern für den gesamten Geschäftsprozess. Sind daran zehn oder zwölf Teams beteiligt, weiß oft keiner genau, ob die aufeinander zulaufen. Gesamtqualitätssicherung wird damit wieder ein großes Thema, und Testmanager werden gesucht.

In der Praxis verwächst die Arbeit von Entwicklung und Test zunehmend. Der Entwickler liefert viel auf der Qualitätsseite: Unit Tests, Code Reviews, statische Analyse, Vorbereitung der Automatisierung. Das Test-Know-how muss dazukommen, sodass beide Professionen zusammenfinden. Das Ziel: ein Tester, der entwickeln kann, ein Entwickler, der testen kann.

Neugier schlaegt die Angst vor KI

Wer als Tester neugierig bleibt, muss sich um die eigene Zukunft wenig sorgen. Die Branche hat sich über Jahre permanent verändert, und das Interesse an Neuem ist hoch geblieben.

Latente Angst gibt es trotzdem, vor allem rund um KI und Werkzeuge wie ChatGPT. Die Sorge, überflüssig zu werden, ist nicht neu: Tester galten schon immer als verzichtbar und waren es dann doch nie. Inhaltlich verändern sich die Rollen, der grundsätzliche Auftrag bleibt.

Zur Neugier gehört auch die persönliche Entwicklung. Test steht oft unter Druck und Stress, mit der ständigen Frage, wie viel zu testen ist und wo automatisiert werden soll. Menschen mental fit für diesen Change-Prozess zu machen, lösungsorientiert und zukunftsoptimistisch, ist eine eigene Aufgabe. Auf diesem Weg bleibt sonst viel liegen.

Wie du als Tester im agilen Team wirkst

Selbstbewusstsein und Coaching wirken besser als der erhobene Zeigefinger. Wer aus tiefem Selbstvertrauen in den eigenen Techniken heraus anderen hilft, nimmt das Team mit, statt es zu belehren.

Der erhobene Zeigefinger kommt immer dann, wenn ich von oben runter gucke, weil ich selber mir nicht so sicher bin, ob ich richtig liege. — Martin Klonk

Ein konkretes Beispiel: Ein Team hatte Prüfregeln nur positiv getestet, also nur geprüft, ob die Regel anschlägt. Im Code steckten jedoch zahlreiche Verzweigungen. Wer das Team dann beiseitenimmt und gemeinsam eine Entscheidungstabelle aufbaut, zeigt ganz praktisch, wie viel mehr aus dieser Prüfung herauszuholen ist. Dabei geht manchem ein Licht auf.

Diese Haltung lässt sich in drei Punkten bündeln:

• Verschreib dich im Team bewusst der Qualität und arbeite ingenieurmäßig, statt einfach drauflos zu testen.
• Tritt selbstbewusst und erklärend auf, nimm Entwickler und Fachbereiche mit, statt von oben zu fordern.
• Frag bei jedem Test, ob er wirklich Mehrwert bringt. Du kannst nicht alles testen, und nicht jeder Test zahlt sich aus.