Warum agiles Testen immer relevanter wird

Time-to-Market ist aktuell der dominierende Wettbewerbsfaktor. Durch Einsatz agiler Entwicklungsmethoden wie Scrum, Kanban, XP und Co. kann die Time-to-Market erheblich verkürzt werden – bei gleichzeitig besserer Ausrichtung an den Kundenanforderungen und ohne an Qualität einzubüßen. Das sind die Versprechen der Methoden und gleichzeitig die Erwartungshaltungen der Anwender.

In und um das Rhein Main Gebiet / Frankfurt, Wiesbaden, dem Wirkungskreis als Softwaretester des Autors, spielt die Ablösung von Mainframeserver Anwendungen und PSD2 eine Rolle bei Banken und Versicherungen. Das Knowhow für diese Anwendungen ist gesucht und neue Lösungen müssen zwingend etabliert werden.

Mit “open banking” / PSD2 verändert sich die IT-Infrastruktur von Banken. Service-orientierte Plattformen mit sicheren Schnittstellen im Backend müssen mit self-service orientierten Frontends verknüpft werden.

Eine Herausforderung für die Kreditinstitute. Das Management von vielen Unternehmen, inklusive traditionell konservativen und extensiven regulatorischen Anforderungen konservativen Branchen wie Banken und Versicherungen stellen also auf agile Methoden um – es muss sich viel verändern.

Agile Methoden sind oft das mittel der Wahl, auch um junge Softwareentwickler überhaupt anzuwerben, denn agile Methoden versprechen im Job auch Spaß, Selbstorganisation und Erfolgserlebnisse.

Die Entwicklungszeiten für Teile (“Iterationen”) von Software sind durch die Anwendung von agilen Methoden wie SCRUM oder Kanban enorm verkürzt. Dies ist einer der Hauptgründe – wenn nicht der Hauptgrund – für die agile Softwareentwicklung. Lassen Sie uns also kurz darauf eingehen, warum agile Softwareentwicklung schneller ist als klassische Wasserfall-Methoden.

Warum wirken agile Methoden beschleunigend?

Schnelle Iterationen werden möglich durch die starke Weiterentwicklung von technischen Werkzeugen. Es gibt spezielle Werkzeuge für unterschiedliche Anforderungen, die es den Teams immer leichter machen, schneller brauchbare Software zu entwickeln. Dies beschleunigt agiles Testen.

Ein weiterer Grund: die Teams organisieren sich selbst. Selbstorganisation, kurze Kommunikationswege und direkte Partizipation des Kunden. Die hohe Geschwindigkeit und der hohe Grad der Selbstorganisation sind die Schokoladenseite der agilen Softwareentwicklung. Der Nachteil –  es folgt daraus, dass agiles Testen ein stressiger Job mit vielen Herausforderungen ist. Doch eins nach dem Anderen. Lassen Sie uns die Vorteile von agilem Testen herausarbeiten.

Vorteile von Softwaretests in agilen Projekten

Die erste Frage, die sich förmlich aufdrängt ist: wenn agile Softwareentwicklung so schnell und mit Tools “einfach” ist, warum dann überhaupt (intensiv) Testen?

Die Antwort ist, dass Tests zwar in dem Entwicklungsprojekt logischerweise Kosten erzeugen (Personalkosten für den agilen Tester, Werkzeuge, Testmanagement etc.). Doch auch, und ich behaupte besonders, in agilen Projekten, rächen sich zu späte oder keine Tests in der Produktivphase der Software mit möglicherweise kaum zu beziffernden Kosten für Nacharbeiten oder Mängelbeseitigungen. Schlechte Softwarequalität kann einen enormen Imageschaden des Softwareanbieters bewirken. Tests sind meiner Meinung nach daher in fast jedem agilen Softwareentwicklungsprojekt ein Muss.

Die Vorteile sind, dass frühe agiles Testen zu besserer Software führen kann, da der Fokus auf die Anforderungen liegt und over-engineering vermieden wird. Durch die Tests wird außerdem die (doch rechte dürftige) Dokumentation bei typischen agilen Projekten bis zu einem gewissen Grad kompensiert. Man kann sich später die Testfälle ansehen und sich damit schnell einen Überblick über Lücken, Fehler und Funktionsumfänge der Software verschaffen.

Anderen im Team auf die Fingern gucken, Hinterfragen, für Klarheit sorgen, Fehler dokumentieren – und dies, wenn die Anforderungen unklar und komplex sind. Der agile Tester hat eine Rolle mit viel Konfliktpotential. Lassen Sie uns darum auf einige Herausforderungen für die agilen Tester eingehen.

Herausforderungen für agile Tester

Herausforderungen für agiles Testen aus Testersicht entstehen häufig aus der Rolle des Testers selbst. Diese Konflikte speisen sich unter anderem aus zwei Faktoren.

Erstens, bei der agilen Softwareentwicklung wird unter hohem Druck eng zusammengearbeitet. Wir sind alle nur Menschen und unter einem, durch die agile Methode inhärenten Zeitdruck (Timeboxing) entstehen meiner Meinung nach zwangsläufig Spannungen. Ein Mensch arbeitet gut unter Stress. Der Andere braucht seine Ruhe, um Sachen gut durchdenken zu können. Gerade auf der zwischenmenschlichen Ebene kann es in dieser Situation schnell zu Meinungsverschiedenheiten und Missverständnissen kommen.

Zweitens, in agilen Projekten tobt meiner Meinung nach immer ein ständiger Diskurs um die Qualität der Software. Die Kunden bzw. Product Owner haben verständlicherweise den Wunsch die Software so vollständig wie möglich zu machen. Doch anfangs unscharfe Vorgaben des Projektes, des Business Analysten bzw. Owners bzw. zu optimistischen Schätzungen am Anfang des Sprints machen es unrealistisch überhaupt die Sprint-Ziele mit einer akzeptablen Qualität zu erreichen. Der Owner schiebt in der Sprint-Planning zu große Features in den Sprint und das Team denkt, dass diese sich umsetzen lassen. Doch der Teufel steckt im Detail, alles dauert länger als geplant. Fehler schleichen sich ein. Eine negative Dynamik beginnt: der PO wird unruhig, denn er kann seine Termine zum Kunden oder dem Management nicht mehr halten. Das Team hat Druck und Misserfolge. Die agilen Tester stellen immer mehr Fehler fest und verkrachen sich mit dem Entwickler. Der Entwickler weiß nicht wo er anfangen soll: Bugs verhindern die Weiterentwicklung, ggf. fallen Teammitglieder aus, neue Entwickler oder Tester kommen dazu, diese wissen anfangs nicht wo sie stehen – die Abwärtsspirale der Qualität geht weiter.

Was für den geübten Agilsten alles richtig und gewünscht ist – genau das obige Szenario ist eine Herausforderungen für den Test, denn: Kunden lassen sich zudem in den Tests neue oder andere Anforderungen einfallen. Der erste Schritt ist meiner Meinung nach ein Problembewusstsein und ein Absetzen der rosaroten Brille für agile Projekte. Die Frage ist also, wie man die Zusammenarbeit verbessern kann. Mehr dazu im nächsten Abschnitt.

Besseres agiles Testen – Möglichkeiten der besseren Zusammenarbeit

Gerade in agilen Projekten zeichnet sich eine saubere Rollentrennung und ein Teamgeist aus. Jeder sollte konstruktiv unterstützen. Alle sollen am gleichen Strang ziehen aber jeder muss sich auf seine Aufgaben konzentrieren können. Ein guter agiler Coach sollte den Teams und den agilen Testern immer mit Rat und Tat zur Seite stehen um Rollenkonflikte und damit aktiv obig skizzierte Schieflagen vermeiden. Teams müssen zusammenwachsen können und dabei auch Fehler machen dürfen.

Was nicht korrekt oder vollständig umgesetzt ist, bedeutet Frust für das Team. Doch hier kann der Ausweg sein, in den Sprint Retros sich den Frust von der Seele zu reden. Die Retros sollten als eine Art Ventil verstanden werden, um konstruktiv Verbesserungen für das agile Testen vorzunehmen. Aus meiner Erfahrung jedoch wird in den Retros oft hinter dem Berg gehalten (vor Allem, wenn der Kunde dabei ist). Gerade als neuer Tester traut man sich nicht die Dinge zu kritisch anzusprechen bzw. frisst den Frust in sich hinein. Ein guter agiler Coach spürt dies und kitzelt das Feedback aus den Teammitgliedern heraus.

Ebenso kann sich die Dynamik zwischen den Entwicklern und den Testern negativ aufschaukeln. Der agile Tester wartet auf den Entwickler: der Entwickler hat Zeitdruck und kann die umgesetzten Lösungen nicht ausgiebig testen. Der agile Tester kennt die Lösung nicht, es gibt keine Dokumentation: ein agiles Test-Vakuum. Was soll man testen – soll sich der Tester alles selbst ausdenken?  Natürlich nicht, den der Tester ist auf die anderen angewiesen, genau wie die anderen auch auf ihn angewiesen sind. Umso wichtiger ist dabei, dass die Projektleitung agile Software nicht nur als MIttel zum Zweck (für Beschleunigung der Entwicklung) einsetzt, sondern dass agile Softwareentwicklung mit agilem Testen tatsächlich mit agilen Werten untermauert wird:

  • Commitment
  • Einfachheit (Simplicity)
  • Feedback
  • Fokus (Focus)
  • Kommunikation (Communication)
  • Mut (Courage)
  • Offenheit (Openness)
  • Respekt (Respect)

Wenn der Zeitdruck gegen Ende des Sprints immer stärker wird: gerade dann muss ein agiler Coach den Teams zur Seite stehen:

  1. Wenn die Entwickler dem agilen Tester keine oder nur wenig Unterstützung geben, bzw.
  2. die Product Owner im Sprint-Planning zu viel Last einplanen, oder
  3. den Testern immer “herein geredet wird” von Seiten von den “Nicht-Testern”.

Bei diesen drei Fällen kann der Tester sein volles Potential nicht auf die Straße bringen.

Der agile Tester der braucht fachliche Unterstützung technische Unterstützung. Der agile Coach muss daher unmissverständlich klar machen: Die Tester ist gerade in agilen Entwicklungsprojekten kein Gegner sondern für die Qualität verantwortlich. Kein Gegeneinander – nur ein MIteinander! Was nach sozialromantik klingt, ist schwer umsetzbar – überall reibt und knirscht es im hektischen Projektgeschäft. An diesen “weichen” kommunikativen Skills setzen oft belächelte Coaching methoden wie GFK (Gewaltfreie Kommunikation) an: definitiv lohnt es sich, sich damit zu beschäftigen.

Streitpunkt bei agilen Methoden ist immer die Qualität, weil die Zeit durch das rigorose Timeboxing fest definiert ist. Eine Alternative, und für manche Projekte mit sehr hohem Qualitätsanspruch passenderes Modell, kann ein hybrides Vorgehensmodell sein. Dabei werden agile Entwicklungszyklen mit eingebetteten agilen Testern durchgeführt und dann als eigene Phasen separate QS-Sprints nachgelagert durchgeführt. Insbesondere vor Auslieferungen können damit die Projektrisiken minimiert werden.

Herausforderungen für agiles Testen liegen in der Umstellung von Wasserfall, V-Modell Organisationen oder Projekten auf agile Methoden. Wenn Projekte von klassischen Vorgehen auf agile Methoden umgestellt werden, dann ist dies für die Teams und damit auch für die Tester eine besondere Herausforderung. Die Rolle des Tests kann sich durch die Methode dramatisch verändern. Agile Methoden jenseits vom Hype tatsächlich nachhaltig in Projekten einzusetzen ist schwer, doch machbar! Agile Tester braucht das Land – und Fehler machen ist OK: wenn man dabei lernt.

Über den Autor

Christian Ehlert ist Unternehmensberater mit mehr als 10 Jahren Erfahrung im Bereich Softwaretest in Frankfurt. Mehr Informationen finden Sie über den Autor auf seiner Seite unter www.ehlert.consulting.

Schreib einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.