Agile Testing - eine Domäne von high performing Teams

Kleine Wasserfälle und ihr Einfluss auf die Performance

Die Tester, Entwickler, Scrum Master, Product Owner unter euch, die diesen Artikel lesen, kennen das Problem: die Entwickler sind zwei oder sogar drei Wochen am Entwickeln, der Sprint näher sich dem Ende. Noch muss die QA ("Quality Assurance") das Inkrement als "done" abstempeln bevor es offiziell wird. Und dann passiert es wieder: Im Inkrement wurde ein Fehler gefunden, es kommt zurück und die Suche nach den Bugs fängt an. In diesem Moment liegen bereits alle Nerven blank. Das Sprintziel ist gefährdet. Niemand weiß, wie lange es dauern wird und der Kunde wartet ungeduldig auf die neuen Features, die ihm mehrmals versprochen wurden. Wird wieder nachts gearbeitet, um das Sprintziel zu erreichen? Wird QA genug Zeit haben, um alle Tests auszuführen? Oder entscheidet sich das Team den Sprint zu verlängern? Klingt wie eine Wahl zwischen Pest und Cholera. Dem agilen Manifest entspricht es in keinster Weise. Und leider haben wir solche Szenarios unzählige Male bei Kunden gesehen.

Der oft sequentielle Prozess der Software-Entwicklung mit aufeinander bauenden Phasen bringt viele Herausforderungen mit sich. Der Einbau der Qualitätssicherung am Ende dieses Prozesses ist eine davon. Bei Pragtics wissen wir, dass sich damit schnell ein mittelgroßer Wasserfall innerhalb des eigentlich agilen Entwicklungsprozesses ergibt. Die Qualität lässt sich aber besser in die Entwicklung einbauen und mit dem Agilen Manifest vereinen. "Aber wie?" Die Antwort ist verblüffend simpel: mit dem Agile Testing.

Was Agile Testing für ein Unternehmen bedeutet

Der Grund, warum viele Teams und Unternehmen Agile Testing ausschließen, ist ziemlich einfach: der Change und die Herausforderungen, die mit ihm einhergehen, fordern Mut und Offenheit. Agile Testing definiert die Rolle von QA und Entwicklern neu, verlangt engere Zusammenarbeit und quasi Obsession mit der Qualität vom gesamten Team.

Schön, aber was bedeuten diese Ausführungen genau? Wir sagen nicht, dass die hier beschriebenen Änderungen einfach sind. Längerfristig bedeuten sie jedoch:

• zufriedenere Mitarbeiter
• höhere Geschwindigkeit

Wie werden die Probleme gelöst? Agile Testing in Praxis

Die Software-Entwickler bauen die Qualitätskontrolle in die laufende Entwicklung ein. Jede Änderung am Code wird zeitnah getestet. Keine Batches mehr, die viele Features beinhalten und wenige Tage vor Sprint-Ende getestet werden müssen. Im besten Fall keine Nachtschichten für die QA und die Entwicklung kurz vor dem Review. Die Bugs werden früh in der Entwicklung entdeckt. Die Reaktionszeit verkürzt sich dramatisch. Die Qualität des Codes und Bereitschaft ausgeliefert zu werden steigen viel früher an. Test Driven Development (TDD) oder Pair Programming bekannt aus eXtreme Programming (XP) sind in diesem Fall gute Orientierungspunkte um zu starten. Entwickler und die QA schreiben z.B. gemeinsam Tests (oder deren Spezifikationen), die dem zu produzierenden Code einen festen Rahmen geben. Vermeiden von langen Tagen, viel Zusammenarbeit, früher bessere Ergebnisse führt bestimmt zu zufriedeneren Mitarbeitern. Fail fast faster!

Höhere Geschwindigkeit ist echt ein Reizwort. Egal, ob man es als Entwickler, QA-Engineer oder Scrum Master hört. Wenn man es nur aus einem skeptischen Blickwinkel betrachtet, kostet Agile Testing sogar mehr Zeit, als das zuvor gelebte Wasserfallmodell. Man soll sich auf einmal zu zweit an die Testentwicklung setzen, man hat viele Abstimmungsrunden, man hat ggf. sogar Konflikte, die erst gelöst werden müssen. Betrachtet man es allerdings aus der Sicht des Lebenszyklus eines Features, so wird schnell klar, dass es viel günstiger ist, Bugs so früh wie möglich (z.B. beim Codieren) zu finden, als diese durch den Kunden entdecken zu lassen. Testen zum richtigen Zeitpunkt zahlt sich aus. Wortwörtlich.

Die Tatsache, dass Software und QA-Engineers Tests zusammen schreiben, bedeutet aber noch lange nicht, dass die QA nichts mehr zu tun hat. So evaluieren sie z.B. Features mit einem Schwerpunkt auf die Qualitätssicherung oder stehen den Entwicklern als Berater für passende Teststrategien zur Verfügung. Die QA spielt ebenso eine große Rolle bei der Formulierung der DoD oder von Akzeptanzkriterien und unterstützen damit die langfristige Qualität. Sie sehen das entstehende Produkt mit der Brille der Enduser und wissen oft (nicht immer) viel besser als Entwickler, wie die Software genutzt wird und was kaputtgehen kann.

Am Ende sind es aber die Menschen, bei denen man wie bei jeder Veränderung anfangen sollte. Mut sich in neue Tätigkeiten einzuarbeiten, zu experimentieren und Fehler zu machen, um aus ihnen zu lernen, sind sicherlich nicht die einzigen, aber auf jeden Fall sehr wichtige Voraussetzungen für Agile Testing. Es sind Menschen, die als erste die wichtigste Frage stellen werden: "Warum?". Die Antwort darauf soll dir jetzt leichtfallen.

‍

Bilder und sonstige Dankeschöns!

• Titelbild: Foto von David Travis auf Unsplash