Agiles Testen in der Praxis mit SCRUM

Agiles Testen – wie klappt das in der Praxis?

Agiles Testen – wie funktioniert das in der Praxis? Seit über 10 Jahren begleite ich bei meinen Kunden auch „agile Projekte“. Nie habe ich dabei ein Vorgehen angetroffen, das 100% einer Methodik folgt und immer gab es noch eine „klassische Welt“, mit der die agilen Methoden harmonieren mussten. Hier bekommst du einen Einblick, wie ich dabei mit einem SCRUM Entwicklungsprojekt vorgehe.

AGILES TESTEN

WAS IST DAS?​

Eine „moderne“ Wortschöpfung, die marketingtechnisch ausgenutzt wird. Zumindest ist das mein erster Impuls. Das agile Manifest definiert Werte und skizziert auch ein mögliches Vorgehen. Das Thema Test wurde dabei aber fast komplett ignoriert – zumindest das Testen, wie du es aus dem klassischen Vorgehen kennst.

Seit 2014 gibt es beim ISTQB einen Syllabus, der sich dem „Agile Tester“ widmet. Dieser ist 2017 auch als deutsche Fassung herausgekommen. Dort wird die Rolle des agilen Tests folgendermaßen beschrieben: „Ein Tester in einem agilen Projekt arbeitet anders als ein Tester in einem traditionellen Projekt. Tester müssen die Werte und Prinzipien verstehen, die agile Projekte stützen. Sie müssen verstehen, dass Tester genauso wie Entwickler und Fachbereichsvertreter gleichberechtigte Mitglieder des Teams sind (Whole-Team-Approach). Sie kommunizieren von Beginn an regelmäßig miteinander, was der frühzeitigen Fehlerreduzierung dient und hilft ein qualitativ hochwertiges Produkt zu liefern.“ [ISTQB1]

Ich verstehe unter agilem Testen alle Testaktivitäten, die notwendig sind, um eine funktionierende Software störungsfrei in Produktion zu bringen. Welche Testaktivitäten für dein Vorhaben notwendig sind und in welchem Zeitfenster du diese durchführen musst, muss für die jeweilige Herangehensweise, aber vor allem für die einzelne Organisation herausgefunden werden. Der Unterschied zu den klassischen Testprozessen ist vor allem der Faktor Zeit, denn agiles Testen soll die agilen Ziele unterstützen. Ferner sind die Testaufgaben nicht nur Sache des Testers, sondern das ganze Team zeichnet sich dafür verantwortlich.

Tester und Testmanager

WERDEN (KLASSISCHE) TESTER UND TESTMANAGER WEITERHIN BENÖTIGT?​

Die klassischen Rollen müssen sich bei agilen Methoden auf Veränderungen einstellen, denn nicht nur der Rahmen ändert sich (wie z.B. Prozesse, Tools, Organisationsform, etc.), sondern es werden ein hoher Automatisierungsgrad und kurze Lieferzyklen angestrebt. Einen „klassischen“ Testmanager gibt es in der Form bei agilen Vorgehen nicht mehr. Es gibt allerdings Ansätze, bei der Testmanager (mit welchem Titel auch immer) für einen „Verbund“ von mehreren Teams zuständig sind (z.B. im Tribe bei dem Spotify-Modell oder als Testmaster). Tester werden in agile Teams eingebettet und übernehmen dort ihre Aufgaben deutlich verzahnter als beim klassischen Vorgehen. Eventuell gibt es aber auch keine dedizierten Tester, sondern jeder kümmert sich um Testaufgaben.

Im Folgenden möchte ich dir aufzeigen, welche Testaufgaben ich in einem agilen Projekt sehe. In einer agilen Organisation oder mit anderen Vorgehen kann das natürlich stark variieren, aber im großen und ganzen muss man die benötigte Qualität erreichen – egal mit welchen Mitteln.

AGILES TESTEN IN AGILEN PROJEKTEN​

Ein Beispiel: Projekt mit Scrum Entwicklungsteam

Ein Projekt, das mit agilen Vorgehen aufgesetzt wird (z.B. SCRUM), benötigt auch eine dazu passende Teststrategie. Welche Qualitätskriterien sind für die zu schaffende Anwendung relevant und wie kann die gewünschte Qualität sichergestellt werden?

Wenn du ein solches Projekt aufsetzt, musst du natürlich die Rahmenbedingungen deines Unternehmens und des Projektes kennen und dir Gedanken machen, was von wem und wann zu leisten ist. Ich habe skizziert, wie ein Projekt mit SCRUM in mehreren Iterationen zur fertigen Software (MVP, minimum viable product) kommt, die dann geliefert und in Produktion genommen wird. Dies ist natürlich nur eine sehr vereinfachte Darstellung, aber sie soll zeigen, wann welche Testaufgaben relevant sein könnten.

SCRUM Agiles Testen Testaufgaben - 7 Tipps

PRODUCT/SPRINT BACKLOG​ - Testaufgaben im Rahmen der Anforderungen

Während sich jemand um die Ausformulierung der Anforderungen (Requirements) kümmert, müssen auch Akzeptanzkriterien definiert werden. Diese sind die Grundlage für die (minimal) durchzuführenden Tests. Hier kann jemand mit Testerfahrung bereits sehr früh Hinweise geben, was alles überprüft werden sollte und damit dabei helfen, die Anforderung klar zu formulieren. Bei SCRUM geht funktionierende Software über die Dokumentation, aber die Akzeptanzkriterien sollten trotzdem klar sein. Auf dieser Basis können auch bereits Testfälle entstehen.

In jedem weiteren Sprint werden weitere Anforderungen verfeinert oder ergänzt und damit fallen auch hier weitere Testaufgaben an. Es empfiehlt sich deshalb die testrelevanten Aufgaben in der DoR (Definition of Ready) bereits mit zu verankern.

SPRINT - ENTWICKLUNG & TEST​

Sprint 1 bis (n-1)

Während die einzelnen Features im Sprint umgesetzt werden, müssen alle relevanten Tests vorbereitet und ausgeführt werden. Gefundene Fehler müssen entweder direkt beseitigt oder als Fehler dem Fehlermanagement zugeführt werden. Jeder Entwickler erstellt Unit Tests für seinen Code, führt diese lokal aus und wenn alles funktioniert, checkt er Code und Testfälle ein. Mindestens ein Mal pro Tag findet dann ein „daily build“ statt. Hier wird sämtlicher Code integriert und zusammen getestet. Dieses daily build sollte fehlerfrei durchlaufen werden, denn ansonsten sind umfangreichere Tests meist behindert und die Testaussage wird erschwert. Ist der Unit Test erfolgreich, wird ein Systemtest inklusive GUI gestartet. Auch diesen sehe ich hoch automatisiert und im daily build.

Nun kommt es darauf an, wie die Qualitätskriterien bewertet wurden, aber ich gehe davon aus, dass es weitere Systeme in deinem Unternehmen gibt, mit denen die neue Software integriert werden muss. Ist z.B. eine neue Schnittstelle hinzugekommen, wurde diese im Systemtest aus Sicht deines Projektes bereits getestet. Aber wie steht es um die reale Integration? Können die beiden Systeme korrekt zusammenarbeiten? Dies solltest du mit einem Systemintegrationstest testen, um nicht später böse Überraschungen zu erleben. Und dann sind da noch die nichtfunktionalen Anforderungen. Ist das System z.B. performant genug? Wurden durch Änderungen im Code Leistungsparameter verändert? Ein nichtfunktionaler Test (NFT) ist meist aufwendig, denn häufig Bedarf es größerer Vorbereitung (z.B. Testdaten) und auch die Laufzeiten sprengen in der Regel einen daily build. Es empfiehlt sich aber NFTs anhand von Bewertungskriterien regelmäßig einzuplanen (z.B. weekly, vor jedem Release, etc.).

Letzter Sprint (MVP)

Spätestens im letzten Sprint vor dem Release gibt es vermutlich auch bei dir noch einige spezielle Testaufgaben zu erledigen. Ein NFT muss auf produktionsnaher oder der neuen Produktionsplattform durchgeführt werden. Ist ein Abnahmetest mit einem Fachbereich oder weiteren Systemen durchzuführen, dann muss auch dieser mit Unterstützung des Scrum Teams eingeplant werden. Als Basis dafür bietet sich ein Reporting an, das sowohl die Testabdeckung über die Projektlaufzeit, die Testergebnisse und die KPIs für einen Qualitäts-Check aufzeigt.

Leitplanken im Unternehmen

Release, Rollout und Betrieb 

Sind alle Hürden genommen und die Software kann produktiv gehen, dann müssen dafür natürlich auch die Voraussetzungen geschaffen worden sein. Wer betreut die Software in Produktion? Wer kümmert sich um Fehler und Störungen? Ein eigenes DevOps Team oder das SCRUM Team? Sind ITIL Prozesse notwendig und aufgesetzt worden? Bei einem Übergang der Verantwortung muss frühzeitig ein Know-How Transfer stattfinden inklusive der Testaufgaben. Wenn du dich um das alles gekümmert hast, steht jetzt der Produktivsetzung nichts mehr im Wege.

Services

Damit sich ein Scrum Team nicht um alle Basisaufgaben selber kümmern muss, können (Test-)services durch zentrale Einheiten aber auf jeden Fall teamübergreifend (z.B. Tribes, Gilden oder ganz klassisch in eigenen Teams) bereitgestellt werden. Wie werden Testumgebungen zur Verfügung gestellt (Hardware, Infrastruktur, Setup und Teardown, etc.)? Wie kommt ein Team an realistische Testdaten (z.B. anonymisiert aus Produktion)? Wie funktioniert ein Test mit anderen Anwendungen und wer stellt diese bereit? Wie sieht das Reporting und die KPIs bezüglich Test aus? Und vor allem: wer kümmert sich um Tools und deren Betrieb?

Alle diese Fragen gilt es zu klären und du musst eine Lösung für dein Projekt finden. Dies kann natürlich alles im Projekt bewerkstelligt werden, aber wiederkehrende Aufgaben für unterschiedliche Teams bringen potentiell keinen Mehrwert, sondern halten von den eigentlichen Aufgaben ab. Bei all diesen Themen muss und soll es natürlich eine Beteiligung des Scrum Teams geben, aber je mehr bereits vorhanden und wiederverwendet werden kann, desto weniger müssen sich alle anderen damit aufhalten. Das Rad muss auch nicht jeden Tag neu erfunden werden.

Meine 7 Tipps für agiles Testen

Im Rahmen einiger Projekte, die nach SCRUM, KANBAN aber vor allem auch Mischformen von klassisch und agil sehr gut funktioniert haben, kann ich dir ein paar Hinweise geben, worauf du achten solltest.

Ich habe dein interesse geweckt?

Dann nutze jetzt die Gelegenheit und nimm Kontakt zu mir auf!