Unit-Tests erkennen Seiteneffekte
Code-Änderungen führen häufig zu unerwünschten Seiteneffekten, die von automatisierten Unit-Tests zuverlässig aufgedeckt und so vor der Auslieferung behoben werden können. Hingegen taugen Unit-Tests garnicht für das Endecken unerwarteter Situation in der Laufzeitumgebung der Software. Beispiele für solche Situationen sind unterschiedliche Konfigurationen der Test- und Produktionsumgebung, geänderte Routen oder Zugänge zu externen Systemen oder eine von Service C ausgeführte Datenbankmigration, die Service A nicht verträgt. Derartige Situationen führen dazu, dass das System nicht mehr das tut was es soll, was häufig erst zu spät durch einen Benutzenden bemerkt wird. Neben klassischen Unit-Tests brauchen wir etwas anderes: Einen Mechanismus, der die Business-Funktionalität des Systems zur Laufzeit überwacht.
Akzeptanzkriterien beschreiben das System aus Business-Sicht
Ein guter Startpunkt für die Laufzeitüberwachung sind Akzeptanzkriterien. Für fast jede User Story lassen sich Akzeptanzkriterien definieren, welche die konkreten Produkteigenschaften der Story aus Sicht der Benutzenden beschreiben. Dazu ein Beispiel: Es soll ein Marktplatz für Surfmaterial entwickelt werden. Auf dem Marktplatz können einzelne Surfshops ihre Produkte einer größeren Kundschaft anbieten. Eine der ersten Stories ist die Einladefunktion, mit der Betreibende des Marktplatzes potenzielle Surfshops einladen können:
Als Markplatzbetreibender möchte ich Einladungen an einen Surfshop senden.
Für die Story werden zwei einfache Akzeptanzkriterien definiert:
die Einladung wird als Mail versendet
die Einladung enthält einen personalisierten Login-Link
Akzeptanztests überprüfen Akzeptanzkriterien
Fortschrittliche Entwicklungsteams schreiben automatisierte Akzeptanztests, die die Umsetzung der Akzeptanzkriterien einer User Story sicherstellen. Die Tests werden vor jeder Lieferung der Software ausgeführt. Einmal in Produktion, wird die Story nur noch von den Benutzenden getestet. Was soll da schließlich noch schief gehen? Ein paar Beispiele:
der Email-Server ist nicht erreichbar,
ein Admin ändert das SMTP-Passwort,
der Einladungs-Link zeigt auf eine ungültige URL,
die Datenbank oder das CRM sind temporär nicht verfügbar
Einige dieser Fehlerquellen, wie der z.B. Ausfall der Datenbank, werden auch von klassischen Überwachungsfunktionen erkannt. Andere Änderungen, die zu einem nachgelagerten Fehler führen, sind nicht so einfach zu erkennen. Z.B. würde eine Änderung des SMTP-Passworts im Mail-Server ohne Anpassung des Markplatzes zu einem Fehler beim Versenden der Einladungs-Email führen. Betreibende des Marktplatzes würden diesen Fehler relativ schnell bemerken, da z.B. eine Fehlermeldung angezeigt wird. Eleganter wäre allerdings ein automatisierter Alert, der auf Rot geht, sobald keine Emails mehr versendet werden. Der Fehler würde frühzeitig bemerkt und könnte behoben werden, bevor Benutzende über das Problem stolpern.
Während ein zerbrochener Email-Versand noch relativ einfach zu erkennen ist, gestaltet sich das Erkennen einer ungültigen URL schwieriger. Angenommen, die Entwickelnden ändern die in der Einladungs-Email enthaltene Landing-URL, ohne das zugrundeliegende Mail-Template anzupassen. Es gibt keinen automatisieren Test, der die Konsistenz zwischen versendeter URL und tatsächlicher URL sicher stellt. Der eingeladene Surfshop läuft auf einen HTTP 404-Fehler, ist frustriert und geht dem Unternehmen möglicherweise als Kunde verloren. Der Fehler wird zwar im Log protokolliert, es vergeht aber Zeit, bis ein Admin auf den Fehler aufmerksam wird. In dieser Zeit sind mehrere potenzielle Shops vergrault worden.
Laufzeitüberwachung durch kontinuierliches Akzeptanztesten
Eine mögliche Variante den skizzierten Fehler rechtzeitig zu erkennen, ist das Zusammenführen der beiden Ereignisse "Email versendet" und "Erster Shop-Login". Dies könnte z.B. auf Basis der Logfiles geschehen, indem zu jedem Einladungsereignis das zugehörige Login-Ereignis gesucht wird. Ein derartiger Test würde mehrere Fehlersituationen erkennen:
der Email-Versand funktioniert nicht
der in der Email enthaltene Link ist falsch
das Login funktioniert nicht
Das Beispiel zeigt, dass bereits ein relativ einfacher Test ausreicht, um das Funktionieren eines zentralen Features sicherzustellen. Darüber hinaus lässt sich aus den Testergebnisse eine interessante KPI ableiten: Zeit vom Versenden der Email bis zum ersten Anmelden des Verkaufenden.
Der Test hat allerdings eine Schwäche: Eine Fehlersituation wird erst erkannt, nachdem die Funktion von einem richtigen Benutzenden ausgeführt wird. Besser wäre es, wenn der Test automatisiert wird, und die Einladungsfunktion ohne menschliches Zutun regelmäßig getriggert wird. Die Mail könnte an einen Test-User gesendet werden, dessen IMAP-Account automatisiert abgefragt und der in der Mail enthaltene Link per HTTP angefragt wird. Ist das Ergebnis HTTP 200, dann können wir davon ausgehen, dass der Einladungs-Roundtrip funktioniert. Diese Art der Testautomatisierung würde nicht nur sicherstellen, dass das Versenden von Einladungs-Emails funktioniert, sondern dass die Business-Funktionalität "Einladen" funktioniert.
User Stories kontinuierlich überwachen
Die Idee der automatisierten Laufzeitüberwachung von Business-Logik zielt darauf ab, den funktionalen Kern einer User Story zu erkennen und dessen Funktionieren automatisiert sicherzustellen. Es geht also weniger darum zu automatisieren, was die Story auf den ersten Blick tut, sondern vielmehr darum, was mit der Story aus Geschäftssicht erreicht werden soll. Bezogen auf unsere Beispiel-Story heisst dies, dass es nicht um das Senden der Email geht, sondern um die Annahme der versendeten Einladung durch den potenziellen. Erst dann schliesst sich der Kreis, und das erhoffte Geschäftsziel Neukundengewinnung wurde erreicht. Die Idee dieses Beitrags ist folgender Apel: Denkt über den Business-Kern jeder User Story nach und liefert im Zuge der Entwicklung einen Test, der diesen Kern zur Laufzeit kontinuierlich überprüft.