Richtlinien für eine erfolgreiche Teststrategie

Bei LMAX, wo ich eine Zeit lang gearbeitet habe, gibt es umfangreiche, erstklassige, automatisierte Akzeptanztests. LMAX testet jeden Aspekt seines Systems und dies ist in den Entwicklungsprozess integriert. Keine Geschichte gilt als abgeschlossen, wenn nicht jedes damit verbundene Akzeptanzkriterium einen bestandenen, automatisierten Akzeptanztest für das gesamte System aufweist.

Dies ist ein Minimum: normalerweise gibt es mehr als einen Akzeptanztest pro Akzeptanzkriterium. Das wirft die Frage auf: "Was ist ein Akzeptanztest?" Ich hatte vor kurzem eine Diskussion über genau dieses Thema mit einigen Freunden, die versuchten, den Umfang von Akzeptanztests klarer zu definieren. Auslöser war ein Artikel von Mike Wacker von Google, der behauptete, dass es nicht praktikabel sei, "Ende-zu-Ende-Tests durchzuziehen").

Mein Ex-Kollege Adrian erwiderte daraufhin, dass LMAX seit acht oder neun Jahren mit genau dieser Art von komplexen End-to-End-Tests lebt. Dies löste eine Debatte über die Bedeutung von End-to-End-Tests aus, die ich hier erst einmal ausklammern möchte. Ich werde den Begriff "Akzeptanztests" verwenden, um die Art von Tests zu bezeichnen, die in dem Google-Artikel beschrieben wird; ich denke, dass die Intention dieser Tests die ist, die ich mit Akzeptanztests meine. Hier gibt es ein ernsthaftes Problem zu lösen: die Wartbarkeit von Tests.

Sobald Sie eine umfassende Strategie für automatisierte Tests einführen, haben Sie auch das Problem, mit Ihren Tests zu leben. Ich kenne die Details des Testansatzes von Google nicht, aber einige Dinge in Mikes Artikel deuten darauf hin, dass Google einigen allgemeinen Problemen erliegt:

Erstens ist ihr Feedback-Zyklus zu lang! In dem Artikel ist die Rede davon, "jede Nacht" die neueste Version eines Dienstes zu erstellen und zu testen. Das ist unter einigen wenigen, schwierigen Umständen akzeptabel - zum Beispiel, wenn Sie Ihre Software in Hardwaregeräte einbrennen. Ansonsten ist es inakzeptabel langsam und beeinträchtigt den Wert und die Wartbarkeit Ihrer Tests.

Wie mein Ex-Kollege Mike Roberts zu sagen pflegte: "Kontinuierlich ist öfter, als Sie denken". Jede Nacht zu testen ist zu langsam, Sie brauchen wertvolles Feedback viel häufiger als das. Meiner Meinung nach sollten Sie eine Rückmeldung in der Commit-Phase in weniger als 5 Minuten anstreben (weniger als 10 sind verkraftbar, aber unangenehm) und eine Rückmeldung in der Acceptance-Phase in weniger als 30 Minuten (60 sind verkraftbar, aber unangenehm). Ich denke, dass Unit-Tests allein nicht ausreichen, und zwar aus einigen der Gründe, die in dem Google-Artikel genannt werden.

Es gibt Anzeichen für andere Probleme. "Die Entwickler mögen es, weil es die meisten, wenn nicht sogar alle Tests auf andere abwälzt". Ich denke, dass dies ein weit verbreitetes Anti-Muster ist. Es ist wichtig, dass die Entwickler die Akzeptanztests selbst durchführen. Es mag sein, dass in der Anfangsphase ihrer Erstellung jemand in einer anderen Rolle den Test entwirft, aber die Entwickler sind diejenigen, die die Tests verletzen werden, und daher sind sie am besten in der Lage, sie zu korrigieren und zu pflegen. Dies ist für mich ein wesentlicher Teil der Continuous Delivery Feedbackschleife. Ich habe noch nie ein erfolgreiches automatisiertes Testverfahren gesehen, das auf einem separaten QA-Team basiert, das Tests schreibt und pflegt. Der Testaufwand hinkt immer hinterher, und es gibt keine "Kosten" für das Entwicklungsteam, wenn die Tests komplett ungültig werden. Überlassen Sie die Pflege der Tests den Entwicklern, und Sie lösen dieses Problem. Verhindern Sie, dass Release-Kandidaten, die einen Test nicht bestehen, weiterentwickelt werden, indem Sie eine Deployment-Pipeline implementieren und es zur Priorität der Entwickler machen, das System in einem "releasefähigen Zustand" zu halten - was bedeutet, dass alle Tests bestehen.

Der letzte wichtige Aspekt von Akzeptanztests ist, dass sie einfach zu erstellen und leicht zu verstehen sein sollten. Es geht darum sicherzustellen, dass die Infrastruktur, die Ihre Akzeptanztests unterstützt, angemessen gestaltet ist. Sorgen Sie für eine klare Trennung zwischen dem "Was" und dem "Wie". Jeder Testfall soll nur aussagen, "was" das getestete System tun soll, nicht "wie" es das tut. Das bedeutet, dass wir die Spezifikation der Testfälle von den technischen Einzelheiten der Interaktion mit dem zu testenden System abstrahieren müssen.

Der Google-Artikel hat Recht, dass Unit-Tests, insbesondere solche, die im Rahmen eines robusten TDD-Prozesses erstellt werden, äußerst wertvoll und effektiv sind. Sie erzählen jedoch nur einen Teil der Testgeschichte. Akzeptanztests, d.h. das Testen Ihres Systems unter realitätsnahen Bedingungen, sind meiner Meinung nach ein grundlegender Bestandteil einer effektiven Teststrategie. Obwohl Sie theoretisch alles, was Sie brauchen, in Unit-Tests abdecken könnten, sind wir in der Praxis nie klug genug, das herauszufinden. Die Bewertung unserer Software aus der Sicht unserer Benutzer ist der Kern einer Continuous Delivery-Teststrategie.

Zusammenfassung

Hier sind also meine Richtlinien für eine erfolgreiche Teststrategie:

• Automatisieren Sie praktisch alle Ihre Tests.
• Schauen Sie nicht auf Tests, um sie zu verifizieren, sondern um sie zu falsifizieren.
• Lassen Sie nicht los, wenn ein einziger Test fehlschlägt.
• Automatisieren Sie Benutzerszenarien als Akzeptanztests.
• Konzentrieren Sie sich auf kurze Feedbackschleifen (etwa 5 Minuten für Tests in der Commit-Phase und 45 Minuten für Akzeptanztests).

Ein Video, in dem ich einige dieser Themen etwas ausführlicher darstelle, finden Sie hier: https://vimeo.com/channels/pipelineconf/123639468