In diesem Artikel erkläre ich, was Test End to End innerhalb des SAFe® DevOps Health Radars bedeutet und warum es für die Lieferung hochwertiger Software unverzichtbar ist. Bitte beachten Sie, dass alles hier Besprochene unter der Lizenz von Scaled Agile steht und dass das Scaled Agile Framework als Toolbox zu verstehen ist. Nehmen Sie daraus, was zu Ihren Bedürfnissen passt und Ihre Probleme löst.
Wo Test End to End in der Pipeline einzuordnen ist#
In der SAFe DevOps Pipeline entstehen grosse Ideen auf Kunden- und Geschäftsseite und werden in Epics mit einer klaren Hypothese überführt. Danach arbeiten wir in der Collaborate-and-Research-Phase mit dem Kunden zusammen, führen Interviews und Marktforschung durch. Anschliessend definieren wir im Architect-Schritt die minimale Architektur, um die Hypothese zu beweisen. Im Synthesize-Schritt brechen wir das Epic in Features herunter und erstellen eine Roadmap und Vision. Im Develop-Schritt werden Features in User Stories zerlegt, entwickelt und in die Versionsverwaltung eingecheckt. Der Build-Server integriert den Quellcode, kompiliert ihn und führt Unit-Tests durch. Das Ergebnis des Build-Schritts ist ein deploybares Artefakt, das wir nun End-to-End testen.
Was im Test End to End Schritt passiert#
Im Test End to End Schritt validieren wir die Lösung gegen die Akzeptanzkriterien in einer produktionsnahen Umgebung. Während des Build-Schritts haben wir bereits Unit- und Komponententests ausgeführt. Jetzt im Test End to End Schritt führen wir Tests auf Feature-Ebene durch, also System- oder Integrationstests.
Um diese Integrationstests zuverlässig auszuführen, benötigen wir eine Umgebung, die der Produktionsumgebung so nahe wie möglich kommt. Nur so können wir den Testergebnissen vertrauen. Alles muss in der Versionsverwaltung sein, einschliesslich der Konfigurationen der Testumgebungen.
Testdaten#
Um Tests in einer Testumgebung auszuführen, benötigen wir Testdaten. Dieses Thema beginnt im Architect-Schritt, wo wir das System testbar gestalten, und setzt sich im Develop-Schritt fort, wo wir die Testdaten erstellen.
Es ist essenziell, synthetische, produktionsnahe Testdaten zu verwenden. In vielen Projekten sehe ich, dass Produktionsdaten oder anonymisierte Produktionsdaten zum Testen verwendet werden. Das ist zwar möglich, aber nicht empfehlenswert. Wenn Sie Produktionsdaten verwenden, erhalten Sie instabile Tests, weil sich die Daten jederzeit ändern oder entfernt werden können. Ein instabiler Test hat null Wert. Alle Testdaten müssen in der Versionsverwaltung gespeichert sein.
Service-Virtualisierung#
In der Regel hängt Ihr System über Schnittstellen von anderen Systemen ab. Um schnell voranzukommen, müssen Sie von diesen anderen Systemen entkoppelt sein und unabhängig testen können. Das erreichen wir durch Service-Virtualisierung: Wir erstellen Simulatoren für externe Systeme, um unabhängig von deren Release-Zyklen testen zu können.
Das hat den grossen Vorteil, dass wir unsere synthetischen Testdaten auch für die anderen Systeme verwenden können. Wir reichern die Simulatoren mit den korrekten synthetischen Testdaten an, und auch diese Simulatoren müssen in der Versionsverwaltung gepflegt werden.
Nicht-funktionales Testen#
Wir müssen nicht nur funktionale Tests durchführen, sondern auch nicht-funktionale Tests. Nicht-funktionale Anforderungen sind Systemeigenschaften wie Sicherheit, Zuverlässigkeit, Performance, Wartbarkeit, Skalierbarkeit und Benutzerfreundlichkeit. Das sind die sogenannten “-ilities” unseres Systems.
Eine wichtige Unterscheidung: Eine nicht-funktionale Anforderung ist kein Backlog-Item, keine User Story und kein Feature. Sie ist eine Einschränkung auf unserem Backlog, die für alle Backlog-Items gilt.
Die agile Testmatrix#
Um ein klareres Bild der Testautomatisierung zu bekommen, verwende ich die agile Testmatrix, die aus vier Quadranten besteht:
Q1: Unit- und Komponententests#
Das sind die Tests, die wir während des Build-Schritts ausführen. Sie lassen sich leicht automatisieren, und wir verwenden in diesem Bereich testgetriebene Entwicklung.
Q2: Funktionale Tests (User Acceptance Tests)#
Hier führen wir die Akzeptanztests aus, die in Features und User Stories definiert wurden. Wir verwenden Behaviour-Driven Development, um gute Akzeptanzkriterien zu erstellen. Die Tests in diesem Bereich werden vorzugsweise automatisiert.
Q3: Akzeptanztests auf Systemebene#
In diesem Quadranten validieren wir das Verhalten des gesamten Systems, einschliesslich der Interaktionen mit anderen Systemen. Wir verwenden explorative Tests oder Workflow-Tests. Automatisierung ist in diesem Bereich schwierig, und die Wartung dieser Tests ist aufwendig, daher gibt es meist viele manuelle Tests.
Q4: Nicht-funktionale Tests#
Hier führen wir die nicht-funktionalen Anforderungstests gegen unser System aus. Es gibt spezialisierte Tools für Sicherheitstests, Performancetests und mehr. Dank der guten Toolunterstützung lassen sich diese Tests leicht automatisieren, was zu einem hohen Automatisierungsgrad führt.
Das Ergebnis#
Das Ergebnis des Test End to End Schritts ist eine verifizierte Lösung. Wir haben funktionale Tests, Integrationstests, Regressionstests, Performancetests und explorative Tests durchgeführt. Zudem haben wir Testnachweise, die üblicherweise in regulierten Umgebungen benötigt werden.
SAFe DevOps Health Radar Assessment#
Der SAFe DevOps Health Radar bietet ein Reifegradmodell für Test End to End:
- Sit: Tests werden manuell in Umgebungen durchgeführt, die die Produktion nicht nachbilden. Tests finden in grossen Batches während einer geplanten Testphase statt.
- Crawl: Tests sind grösstenteils manuell in nicht-produktionsnahen Umgebungen. Stories werden innerhalb eines einzelnen PI (Drei-Monats-Zyklus) unabhängig implementiert und getestet.
- Walk: Die Hälfte der Tests ist automatisiert und wird in produktionsnahen oder produktionssimulierten Umgebungen pro PI durchgeführt.
- Run: Die Mehrheit der Tests ist automatisiert und läuft in produktionsnahen Umgebungen. Stories werden pro Iteration (Zwei-Wochen-Sprint) implementiert und vollständig getestet.
- Fly: Erfolgreiche Builds lösen automatische Deployments in produktionsnahe Testumgebungen aus. Alle Tests sind automatisiert, laufen parallel, und Änderungen werden nach jedem Commit vollständig validiert.
Test End to End bedeutet, unser System end-to-end in einer produktionsnahen Umgebung zu validieren, und zwar sowohl funktional als auch nicht-funktional. Es ist ein kritischer Schritt in der Continuous Integration Pipeline, der sicherstellt, dass wir verifizierte, hochwertige Lösungen liefern.