7 Tipps für Agiles Testen

Egal wie das Unternehmen strukturiert ist, solltest du dir Gedanken machen, was alles wie zu testen ist. Im klassischen Umfeld kann dies auch ein Master Testkonzept sein. Bei agilen Vorgehen wird dies häufig als Test Charta bezeichnet und sollte möglichst wenig Dokumentation sein. Wichtig für die agilen Teams ist es, dass sie Leitplanken haben, wissen worauf sie sich verlassen können und welchen Anspruch sie erfüllen müssen. In den Teams können viele Testaufgaben selbständig geregelt werden und wenn es keine Abhängigkeiten außerhalb des agilen Teams gibt, wird eine Test Charta vermutlich auch nicht benötigt.

Mit einer Test Charta solltest Du Klarheit über die folgenden Themen haben:

• Welche Testarten sind von den agilen Teams zu berücksichtigen, damit die Software in Produktion gehen kann?
• Wie werden Testumgebungen inklusive Testdaten zur Verfügung gestellt?
• Welche Regeln müssen eingehalten werden (z.B. Umgang mit Testdaten)
• Wer kümmert sich wie um integrative Tests mit anderen Systemen?
• Wie werden Fachbereiche und Stakeholder eingebunden?
• Mit welcher Methodik und welchen Metriken wird gearbeitet?
• Welche Tools werden genutzt und wer kümmert sich um diese?

Eine solche Test Charta ist in der agilen Welt natürlich nicht in Stein gemeißelt und sollte bei Bedarf angepasst werden. Hier kann ein Testmanager / Testmaster hilfreich sein, der Änderungen übergreifend abstimmen kann. Manchmal werden dafür aber auch Gilden gebildet und dort solche übergreifenden Themen besprochen und entschieden.

Dein agiles Team muss die Test Charta nun berücksichtigen. Dies kann in einer Definition of Test (DoT) passieren und/oder als Checklistenpunkte in der Definition of Done (DoD). Zu klären ist: wann und wie werden die notwendigen Testphasen durchgeführt, damit die Software mit ausreichender Qualität geliefert werden kann.

Im klassischen Umfeld gibt es häufig Quality Gates. Hier gibt es harte Kriterien, welche erfüllt sein müssen, damit geliefert werden darf. In einem solchen Umfeld empfiehlt es sich die relevanten Kriterien bereits in der eigenen DoD zu berücksichtigen. Gibt es keine Quality Gates, bietet es sich an, dass du aus operativer Erfahrung lernst und Fehler nur einmal machst. Auch hierbei kann eine Gilde helfen, damit nicht jedes Team dieselben Fehler macht.

Agile Tester sind nicht nur eng mit den Entwicklern vernetzt, sondern auch mit den fachlichen Anforderern. Sind die Anforderungen (engl. Requirements) in User Storys beschrieben, sollte es dazu auch Akzeptanzkriterien geben. Diese sollten in den DoR (Definition of Ready) auch fest verankert werden. Hier kann der Tester behilflich sein, die notwendigen Kriterien zu definieren und einen Test dieser vorzubereiten. Idealerweise wird dies in Form von automatisierten Testfällen umgesetzt, aber viele dieser Akzeptanzkriterien haben auch Bezug zu externen Abhängigkeiten und müssen organisiert werden (Tests über Systemgrenzen hinweg, nichtfunktionale Anforderungen, etc.). Auf Basis der User Storys wird auch die Planung durchgeführt – und damit implizit auch die Testplanung. Manche Akzeptanzkriterien werden erst testbar sein, wenn andere Storys umgesetzt wurden. Achte bei der Planung darauf.

Pipelines mit Continuous Integration (CI) und Continuous Delivery (CD) sind bereits weit verbreitet und bilden das Fundament für einen funktionierenden Buildprozess. Dabei werden häufig innerhalb von 24 Stunden alle Tests immer wieder durchgeführt (Regression). Aber: sind auch alle notwendigen Tests eingebunden? Geht die Testautomatisierung über Unittests hinaus? Werden relevante Nachbarsysteme (oder -services) ebenfalls berücksichtigt?

Spätestens bei der Notwendigkeit von End-2-End-Tests wird dieses Vorgehen torpediert, denn auch andere Systeme müssen vorbereitet und angebunden werden. Deshalb ist es wichtig auch die Integration und die Testautomatisierung mit allen relevanten Partnersystemen zu berücksichtigen. Dies ist idealerweise in der Test Charta geregelt worden und alle beteiligten Teams sind mit an Bord.

Gibt es große Risiken bei der Einführung deines Systems zu beachten, dann müssen diese nicht nur in der Planung, sondern auch bei den Testaufgaben berücksichtigt werden. Baue dein System in Schritten, die (integriert) auch testbar sind und im Verbund funktionieren. So haben wir in Projekten nicht nur Schalter, sondern auch Prozessweichen gebaut und damit das Risiko deutlich minimiert. Immer wieder hilfreich ist es auch möglichst früh die Rolloutstrategie zu berücksichtigen und zu testen. Setzt man beim Aufbau der Testumgebung bereits auf ein Tooling, das später für den Rollout benutzt wird, spart man sich wiederkehrende Arbeit und sichert die Produktivsetzung gleichzeitig ab.

Obwohl die Idee bei Scrum und anderen Vorgehen war, dass jeder alles können muss, würde ich das so nicht unterschreiben. Es ist völlig ausreichend, wenn du alle Aufgaben im Team durch mehr als eine Person leisten kannst und somit kein Engpass bei Urlaub, Krankheit oder ähnlichem entsteht. Ein Großteil des Teams sollte sicher entwickeln können, damit auch etwas abgeliefert werden kann. Aber für Spezifikation und Test ist es hilfreich, wenn auch Spezialisten für diese Themen in deinem Team sind. Durch die verschiedenen Mindsets kommt man zu einem besseren Ganzen. Ein Testmanager / Testmaster kann dabei helfen, alle relevanten Testaufgaben zu erkennen und zu verteilen bzw. einige davon auch auszuführen.

Es gibt verschiedene Möglichkeiten, wie man wiederkehrende Aufgaben und Tooleinführung verteilen kann, aber es sollte immer mindestens einen Ansprechpartner geben, der sich auch darum kümmern kann. Zieht dein Unternehmen in die Cloud und baut dort Testumgebungen auf? Wie bekommt man dort (oder auch on premise) einen neuen Container (oder neues System) mit Datenbank, Firewall-Freischaltung und allem was dazu gehört? Wie bekommst du Zugriff auf die abhängigen Systeme oder eigene? Und wer betreut das alles? Du kannst hier viele Aufgaben Automatisieren und Prozesse sehr schlank halten, aber du brauchst jemanden, der sich damit auskennt und das automatisiert vorbereitet.