Agiles Testen: Mehr Effizienz durch die Testpyramide

In meinem Beitrag „Was agiles Testen nicht ist und was es ist“ habe ich darüber geschrieben, dass Funktionalitäten in einem Sprint fertig getestet werden müssen, um am Ende des Sprints funktionierende (Teil)Produkte liefern zu können. Das kann herausfordernd sein: Man muss frühzeitig wissen, was man testet, die notwendige Infrastruktur muss zur Verfügung stehen und vor allem muss es schnell gehen – denn die Iterationen sind kurz, sehr viel kürzer als wir es aus klassischen Projekten gewohnt sind.
Mike Cohn hat schon vor einigen Jahren die Testpyramide vorgestellt, die uns zeigt, wie das Testen effizient gestaltet werden kann:

Mit dieser Taktik lässt sich die Qualität des Produkts am effizientesten erhöhen und es kann sichergestellt werden, dass am Ende des Sprints funktionierende Software potenziell geliefert werden kann.

Bild: Copyright Mike Cohn, Constanze Riess

Was agiles Testen nicht ist und was es ist

In meinen Projekten höre ich oft Sätze wie „Unser Testing-Team macht auch Scrum, also machen wir agiles Testen“ oder „Wir testen in den Sprints, also machen wir agiles Testen. Und vor dem Release gibt es noch einen Testing-Sprint für die Integrationstests“ oder „Wir testen sprintversetzt – was in einem Sprint entwickelt wurde, testen wir im nächsten“ usw.
Solche und noch viel mehr ähnliche Sätze zeigen mir, wie sehr „agiles Testen“ missverstanden wird. Alle erwähnten Aussagen zeigen mir nur: Es wird weiterhin nach dem Wasserfall entwickelt – nur in kürzeren Iterationen, mehr nicht. Kein agiles Entwickeln und schon gar nicht agiles Testen. Denn was ist „agil“ per Definition?

„Lieferung funktionierender Software in kurzen Iterationen und in Inkrementen.“

Wie aber soll man sicherstellen, dass die Software funktioniert, wenn sie nicht innerhalb einer Iteration getestet wird? Und zwar komplett. Nicht nur ein bisschen, ohne Integrationstests am Ende des Releases, ohne sprintversetzte Tests, sondern alles findet im Sprint statt, sodass am Ende des Sprints ein Stück Software potenziell an den Kunden geliefert werden kann.

Was unterscheidet agiles Testen noch vom klassischen Testen?

Wir wissen, dass das ganze Entwicklungsteam für die Qualität des Produkts verantwortlich ist. Wenn nur die Tester testen, kann von gemeinsamer Verantwortung nicht die Rede sein. Natürlich braucht es weiterhin die Tester im Team. Sie bringen wertvolles Know-how mit, auf das nicht verzichtet werden kann. Dennoch können und sollten alle Teammitglieder ihren Beitrag zur Qualität des Produkts leisten, zum Beispiel so:

Mit anderen Worten: Agiles Testen ist die Gesamtsumme aller Tätigkeiten, die dafür sorgen, dass am Ende jedes Sprints die gelieferten Funktionalitäten funktionieren und vom Kunden potenziell sofort genutzt werden können.

Foto: CC0 Creative Commons, testbytes – pixabay

Pair und Mob Programming – der kleine, aber feine Unterschied

Wissenstransfer, die Ideen und Kompetenzen von vielen nutzen, Einarbeiten neuer Kollegen – Mob und Pair Programming sind wirklich sinnvolle Arten der Zusammenarbeit. Aber wann eignet sich welche der beiden Arbeitsmethoden am besten?

Vier Augen sehen mehr

Beim Pair Programming sitzen zwei Entwickler gleichzeitig vor einem Bildschirm und bilden somit ein „Pair”. Einer der beiden programmiert, der Zweite liest die Codezeilen mit. Nach dem Motto “vier Augen sind besser als zwei” wird so der Code von beiden Entwicklern gleichzeitig geschrieben. Besonderen Charme hat dieses Vorgehen deshalb, weil die beiden Entwickler einerseits besseren und sauberen Code schreiben und sich andererseits gegenseitig zu innovativem Denken motivieren. Der Austausch zwischen den Entwicklern zum geschriebenen Code führt dazu, dass sie voneinander lernen und ihr Wissen erweitern.
Tipp: Nach einer zuvor vereinbarten Zeit sollten Coder und Mitleser sich abwechseln, um Ermüdungserscheinungen (nachlassende Konzentrationsfähigkeit) vorzubeugen.

Komplexe Themen im Team bearbeiten

Beim Mob Programming sitzt das gesamte Team vor einem großen Bildschirm und nur einer aus dem Team programmiert. Die Besonderheit ist hierbei, dass das programmierende Teammitglied nicht seine eigenen Gedanken in Code verwandelt, sondern das restliche Team über den nächsten Codeabschnitt diskutiert. Der Entwickler an der Tastatur muss aus der Diskussion heraushören, wie die nächsten Codezeilen aussehen werden bzw. lässt er sich diese teilweise sogar diktieren (je nach Erfahrungsgrad). Durch die Diskussion wächst nicht nur bei jedem Teammitglied die Erfahrung im Umgang mit komplexen Problemstellungen, sondern gleichzeitig auch das Wissen über den Code. Jeder im Team ist in der Lage, den Code zu verstehen, weiß worum es geht und kann schnell Code Refactoring betreiben.
Tipp: Diese Art des Programmierens ist für denjenigen, der gerade tippt, sehr anstrengend. Daher sollte der codende Entwickler nach ca. 10-15 Minuten von einem anderen Teammitglied abgelöst werden. Bei einer Teammitgliederanzahl von mehr als vier ist es besser, mit einem Beamer zu arbeiten, statt auf einen Bildschirm zu starren. So kann jeder einfach folgen und niemand versperrt einem anderen Teamkollegen die Sicht.

Best Practice

Meine persönliche Erfahrung mit beiden Methoden hat gezeigt, dass es bei neuen Thematiken sinnvoller ist, erstmal gemeinsam zu starten, um eine gemeinsame Laufrichtung zu finden. Im nächsten Schritt sollte man das Team in kleine Pairs aufbrechen, um sich die geschnittenen Themen zu erarbeiten. Nach einiger Zeit trifft man sich wieder als Team im Mob, fügt die Codefragmente zu einem gemeinsamen Code zusammen, testet gemeinsam und bleibt für die weitere Entwicklung im Mob. Oder: Das Team einigt sich auf die nächsten Einzelthemen, die wieder im Pair erarbeitet werden. So entsteht ein angenehmer Arbeitsflow, bei dem das Wissen aller Teammitglieder stark wächst und das Produkt dadurch schnell, effizient, effektiv und erfolgreich geliefert werden kann.

Foto: (c) rawpixel