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:

• Unit Tests sind relativ einfach zu erstellen und auch noch schnell durchzuführen. Wir können diese nutzen, um eine hohe Testabdeckung zu erreichen und in sehr frühen Phasen der Entwicklung die meisten Fehler zu entdecken. Hier hilft es sehr, wenn Entwickler konsequent bei der Erstellung von Unit Tests dabei sind und ein hohes Qualitätsbewusstsein haben. Idealerweise entwickeln sie sogar mit TDD oder folgen den Prinzipien zu Clean Code.
• System- und Integrationstests kann man relativ gut automatisieren, dafür gibt es auch eine große Toolauswahl. Um möglichst effizient zu testen, ist es absolut wichtig, das richtige Tool auszuwählen. Die Kosten dürfen dabei nicht das einzige Entscheidungskriterium sein. Genauso wichtig sind das Know-how der Teammitglieder (Script-Tools, Capture & Replay, Beschreibungssprache etc.), die Interaktion mit den anderen Entwicklungstools und vieles mehr. Aus dieser Testphase heraus lässt sich meiner Meinung nach auch am besten entscheiden, welche Testfälle sich für den Pool an Regressiontest-Testfällen eignen. Meine Empfehlung: mindestens 1 Gutfall-Testfall + 1 kritischer Negativ-Testfall pro User Story. Hier ist auch wichtig zu wissen, ob sich diese User Story in naher Zukunft noch sehr verändern wird (dann mehr Testfälle in den Regressionstest) oder nicht.
• UI/Fachbereichstests sind meist sehr komplex und schwer zu automatisieren. Auch die Wartung der Automatisierung ist sehr zeitintensiv, daher sollte man sich gut überlegen, ob eine Automatisierung tatsächlich sinnvoll ist. In dieser Phase der Entwicklung sollte man eigentlich schon die meisten Fehler gefunden haben. Es geht also nur noch darum, zu verifizieren, ob das Richtige entwickelt wurde und nicht mehr so sehr, ob es richtig entwickelt wurde. Diese Tests sollten natürlich nicht vernachlässigt, aber auf ein Minimum reduziert werden. So spart man Zeit und Geld und vor allem entstehen keine Redundanzen.

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