Während des Projektalltags stellt man sich manchmal die Frage, was mache ich eigentlich hier bzw. wissen die anderen im Team was ich tatsächlich tue? Als Tester habe ich mir diese Frage auch schon gestellt und einige Gedanken zusammengefasst. Daher findet man im Weiteren ein paar Ausschnitte aus meinem Alltag als Tester.
Daily
Wieder ist Daily und ich frage mich als Tester wie ich denn heute die Spezifikation von Testfällen attraktiv als getane, jetzige sowie zukünftige Arbeit verkaufen kann. Im Grunde vollzieht sich das ganze meist mit den Worten “Habe Testfälle für User Story xyz spezifiziert und mache damit weiter.” Etwas eintönig und meist etwas belächelt, aber nun mal die Hauptaufgabe in den ersten Tagen eines Sprints. Schließlich setze ich als Tester doch den Grundstein aktuelle User Stories ordentlich zu testen.
Spannender wird es dann schon, wenn ich mitteile, dass ich nun auch Testfälle durchführe und voller Stolz den ein oder anderen Fehler verifiziert habe. Wobei von Stolz nicht die Rede sein kann. Kommt halt auf die Entwickler, die aktuelle Stimmung im Team, die Priorität des Fehlers oder der Selbstbewusstseinswahrnehmung des Testers (mir) an. Also kann es auch vorkommen, dass vor mich gemurmelt das Wort “Bug” fällt und schnell das Wort an andere übergeben wird. Warum eigentlich diese Zurückhaltung?
Ich als Tester habe die Verantwortung darauf aufmerksam zu machen, wenn etwas in der Software nicht so funktioniert wie definiert. Und das ist auch gut so. Denn wie will man qualitative Software liefern, wenn Fehler nicht akzeptiert sind und zu Stresssituationen oder Konflikten führen. Also nur Mut – der Fehler verschwindet nicht, wenn man ihn nicht anspricht (ganz im Gegenteil, er wächst, umso später er gefixt wird) und schnell ist er auch einmal im Wust der täglichen Entwicklungsarbeit in Vergessenheit geraten, wenn er nur in schriftlicher Form am Taskboard zwischen den großen User Storys hängt.
Regressionstests/Testautomatisierung
Apropos Taskboard – dies ist ein gutes Hilfsmittel die User Storys mit darin enthaltenen Aufgaben und deren Fortschritt im aktuellen Sprint im Auge zu behalten. Wenn man sich die Zeit nimmt, um innezuhalten und die Arbeit im Team mit Hilfe des Taskboards über Wochen oder auch Monate hinweg zu betrachten, könnte man zu folgender Behauptung gelangen: Die Entwickler arbeiten mit glänzenden, neuen Sachen und die Tester wühlen im Dreck der Vergangenheit mit Sicht auf den Glanz des Neuen. Dies bedeutet nicht, dass mir als Tester nicht bewusst wäre, dass Entwickler auch an bestehendem Code Anpassungen vornehmen müssen, und auch mal Bugs fixen. Aber ich als Tester habe eine ganz andere Sicht. Trotz all der automatisierten Tests, die unsere Entwickler schreiben, muss ich den Überblick darüber behalten was alles von Änderungen betroffen ist – ein kontinuierliches Zurückblicken auf Altlasten, während der Programmierer voranstürmt.
Damit sind wir dann auch bei der größten Herausforderung meines Alltags – Regressionstest. Den kann man zwar auch automatisieren, leider sind die Tools dafür aber nicht immer sehr freundlich zu mir. Werden sie nicht von Beginn an eingesetzt, bin ich kontinuierlich damit beschäftigt hinter den Änderungen der Entwickler her zu rennen. Aber selbst wenn ich sie gleich von Anfang an einsetze muss ich sie, um meine eigenen Aufgaben zu erfüllen, auf UI Ebene einsetzen und das ist langwierig und dummerweise eben selbst auch fehleranfällig. Dazu folgende Gedanken:
Testautomatisierungs-Tools suggerieren mir, dass ich durch einfaches Aufzeichnen von Testschritten Testautomatisierung machen kann. Leider wird mir nach anfänglichem Enthusiasmus klar, dass es damit nicht getan ist, da meine Testaufzeichnungen meist keinen Tag überlebt haben. Also auf zu neuen Ufern – diesmal programmieren und Aufzeichnungs-Tools verbannen. Da tauchen auch schon die nächsten Hindernisse auf. Denn ich bin kein guter Programmierer und muss mich nun mit kryptischen Sachen beschäftigen. Doch schon wird die nächste Idee geboren: Die Erfahrung der Entwickler zu Nutze machen. Auch da werden Grenzen gesetzt, denn das geht meist nur so lange gut, wie der Entwickler Zeit dafür hat bzw. gewillt ist, dies zu machen. Verständlich, denn der Entwickler will ja neue Sachen schaffen.
Ich stecke also in einem Zwiespalt: Schreibe ich automatisierte Tests oder mache ich alles manuell. Regressionstest sollte ich auf alle Fälle einplanen. Wie diese nun aussehen – automatisiert, manuell oder explorativ – kommt auf die verschiedensten Rahmenbedingungen an. Für mich ist Testfallautomatisierung jedenfalls kein Allheilmittel. Ich sehe den Mehrwert automatisierter Testfälle, die zu jedem Sprint ausgeführt werden können – größerer Testabdeckung, weniger manuelles Testen von vorgegebenen Workflows. Aber eine reine Testfallautomatisierung ist kein Allheilmittel, denn dies wird meine Testererfahrung und das damit verbundene Verfahren “Über-den-Tellerrand-Hinausblicken” nicht ersetzen.
Fazit
Auf alle Fälle sollte das Testen an sich – egal ob manuelles Testen, Regressionstests oder Testautomatisierung – im Team anerkannt sein und zusammen an der Qualitätssicherung gearbeitet werden. Denn schnell fühlt sich der Tester nicht mehr als Teil des Teams sondern Fremdkörper, wenn seine Arbeit nicht ernst genommen wird.
Dieser Beitrag wurde verfasst von:
