Getestet wird Software schon immer. Auch bei klassischen Vorgehensmodellen ist Testen ein entscheidender Bestandteil des Qualitätsmanagements, denn mangelhafte Testprozesse sind nicht nur eine der Hauptursachen für Fehlfunktionen im Live-Betrieb, sondern auch für Effizienz-Einbußen: Die Wahrscheinlichkeit ist hoch, dass spät entdeckte Bugs die Arbeit des Entwicklerteams im Projektverlauf behindern. Was aber macht agiles Testen so anders, dass ganze Bücher darüber geschrieben werden? Wie ändert sich das Selbstverständnis des Testers und welche Rolle spielt die Testautomatisierung?
Testen ist teuer, oder?
Ein Hauptziel von agilen Projekten ist das frühzeitige Erkennen von Problemen. Und das macht auch aus wirtschaftlicher Sicht Sinn: Nach der sog. „1-10-100-Regel“ nimmt der Aufwand für Korrekturen exponentiell zu, je später Fehler und Probleme entdeckt werden.
Wird der Fehler während der Programmierarbeit vom Entwickler selbst gefunden, lässt er sich rasch und ohne großen Aufwand beheben (Faktor 1). Findet erst ein Tester in der Test-Umgebung einen Bug, steigt der Aufwand deutlich an: Der Fehler wird dokumentiert und dem Entwickler übergeben, und nach der Aktualisierung des Systems muss die Softwareversion erneut getestet werden (Faktor 10). Das Worst-Case-Szenario ist die Entdeckung im Live-Betrieb durch den Nutzer – hier kommen zum erhöhten Aufwand der komplizierten Fehlerbehebung im ausgelieferten System ggf. noch Umsatzeinbußen und der Imageverlust hinzu (Faktor 100).
Die Bedeutung von systematischen und regelmäßigen Tests bereits während der Software-Entwicklung kann deshalb nicht hoch genug eingeschätzt werden. Die Frage ist weniger „Was kostet Testen?“, sondern vielmehr „Wie teuer ist es, nicht (oder nicht gut genug) zu testen?“
Klassisches vs agiles Testen
Das Ziel agiler Frameworks wie z.B. Scrum ist die regelmäßige Auslieferung fertiger Produkt-Inkremente an den Kunden. So wird der Kunde kontinuierlich in den Entwicklungsprozess eingebunden und kann Änderungswünsche möglichst früh erkennen und kommunizieren – ein großer Vorteil zur Abarbeitung eines klassischen Lastenhefts.
Für das Entwicklerteam bedeutet diese iterative Vorgehensweise, dass sich Funktionalitäten und Umfang der Software in vergleichsweise kurzen Intervallen von 2- bis 4-wöchige Sprints ändern UND dass der auszuliefernde Code während jedes Sprints erneut einer sorgfältigen Qualitätsprüfung unterzogen werden muss.
Was bedeutet das für das Test-Volumen und die Test-Frequenz?
Insbesondere bei den ersten Iterationen fällt das Team häufig in das klassische Denkmuster „erst entwickeln – dann testen“ zurück. Wird das Testen der neuen Funktionalitäten aber auf das Sprintende geschoben, ist die Auslieferung gefährdet: Findet das Testteam „5 vor 12“ größere Fehler, kann dem Product Owner beim Sprint-Review kein funktionsfähiges Inkrement übergeben werden.
Agiles Testen bedeutet deshalb, dass Tests nicht nur einmal am Ende einer Iteration ausgeführt werden dürfen, sondern im Normalfall mehrmals täglich. Hinzu kommt, dass die häufigen Releases in kurzen Iterationszeiten eine hohe Zahl an Regressionstests nötig machen, denn jede Änderung kann bereits fertige Funktionalitäten beeinflussen und Fehler produzieren.
Testautomatisierung ist Trumpf
Ohne hier näher auf die Unterschiede zwischen Unit-, Integrations- und Akzeptanztests einzugehen, wird schnell klar: Das traditionelle Schreiben von Testplänen und die rein manuelle Durchführung durch ein Testteam ist im engen zeitlichen Rahmen eines Sprints zeitlich oft nicht realisierbar. Die Testautomatisierung sollte deshalb von Anfang an in die Softwareentwicklung integriert werden – sowohl was den zeitlichen Vorlauf als auch das nötige Know-how anbelangt. Eine Wirtschaftlichkeitsrechnung entscheidet von Fall zu Fall, ob ein manueller Test oder eine Automatisierung sinnvoller ist.
Ein Rechenbeispiel:
Gehen wir von einer Projektdauer von 1 Jahr aus. Sie arbeiten mit 2-Wochen-Sprints und müssen eine bestimmte Softwarefunktion in jeder Iteration testen. Angenommen dieser Test dauert jedesmal 1 Tag, dann „kostet“ ein manueller Test dieser Funktion 26 Manntage. Benötigen Sie für die Programmierung des Skripts für die Test-Automatisierung 2 Wochen, haben Sie nach Adam Riese 12 Manntage eingespart.
Beim agilen Testen wird es noch wichtiger, dass Softwareentwicklung und die Entwicklung der Testautomation parallel erfolgen – bis hin zur testgetriebenen Entwicklung, bei der die Tests noch vor der Software geschrieben werden.
Vervollständigt werden die automatisierten Tests durch exploratives Testen, um die Lücken in der Testabdeckung gezielt zu schließen. Hierbei werden besonders fehleranfällige Bereiche und Funktionen manuell „ausprobiert“, ohne einem vorgegebenen Testplan zu folgen.
Was auf den ersten Blick nach einer Herausforderung bei der Bewältigung des Testumfangs aussieht, bringt in der Realität aber meist sogar Zeitvorteile: Denn Fehler werden nicht erst Wochen oder Monate nach der Programmierung entdeckt, sondern sehr zeitnah – der Entwickler weiß genau, was er während des aktuellen Sprints geändert hat, was den Zeitaufwand für die Fehlersuche deutlich minimiert.
Der neue Typ „Tester“
Den klassischen Tester, der in einem anderen Raum oder sogar in einem anderen Gebäude sitzt und Testpläne abarbeitet, gibt es in agilen Projekten nicht mehr. Der Team-Gedanke steht im Vordergrund, was zu einer Auflösung der strikten Trennung von Entwicklerteam vs Testerteam führt.
Selbstverständlich gibt es in der Praxis Spezialisierungen innerhalb der Teams, aber es ist ein wichtiger Punkt des agilen Konzepts, dass sich das gesamte Projektteam für die Qualität verantwortlich fühlt – im besten Fall kann auch jeder Entwickler automatisierte Tests schreiben oder beim manuellen Testen unterstützen. Das Testen wird also nicht an eine „externe“ Abteilung ausgelagert, sondern die Tester sind Teil des Entwicklerteams, von der User Story bis zur Retrospektive.
Diese Entwicklung erfordert einen neuen Typ Tester, der nicht nur technische Fähigkeiten einbringt, sondern eng mit Entwicklern und Kunden zusammenarbeitet. Ein agiler Tester ist kommunikativ und proaktiv statt auf Anforderungsdokumentationen zu warten. Dieses Wertesystem wurde auch in einem „Agilen Test-Manifest“ anlässlich des 20. QS-Tags in Nürnberg festgehalten.
Doch egal ob Sie klassisch oder agil, manuell oder automatisiert testen: Fehlerfreie Software gibt es nicht. Wohl aber eine Risikominimierung.
Program testing can be used to show the presence of bugs, but never show their absence!
Edsger Wybe Dijkstra, niederländischer Informatik-Pionier
Ziel sollte es immer sein, mit möglichst geringem Aufwand die größtmögliche Wirkung zu erzielen – wir beraten Sie gerne zu einem maßgeschneiderten Test-Konzept für Ihre Projekte oder begleiten Sie bei der Einführung eines Test-Tools!
Beitrag teilen
