Dieser Beitrag soll zeigen, welche zentrale Rolle die Test-Phase im DevOps-Infinity-Loop spielt. Wir werfen einen Blick auf Tools, Frameworks und Methoden, auf die verschiedenen Testarten sowie auf das AWS-Ökosystem und die Services, mit denen sich DevOps Best Practices und insbesondere die Test-Phase umsetzen lassen. Es geht hier nicht um einen rein technischen Beitrag, sondern um einen allgemeinen, informativen Überblick. Sie finden also keine Schritt-für-Schritt-Anleitung zum Aufsetzen einer Pipeline oder zum Deployment in Ihre Infrastruktur, sondern eine Einordnung der wichtigsten Aspekte, Optionen und beteiligten Services.
Test-Phase
DevOps lebt davon, dass Software schnell ausgeliefert wird – idealerweise mit mehreren Deployments pro Tag. Damit das funktioniert, müssen Teams Code innerhalb von Minuten und so häufig wie möglich testen können. Die Test-Phase entscheidet allein anhand der Testergebnisse und ohne manuelles Eingreifen, ob ein Build die nächste Stufe erreicht oder gestoppt wird.
Software zu testen ist ein essenzieller Schritt im Software Development Life Cycle (SDLC). Bugs früh zu erkennen und vor dem Produktiv-Release zu beheben, ist Gold wert. Eine in die Pipeline integrierte Test-Phase hilft dabei, bestehende Fehler zuverlässig aufzudecken. Welche automatisierten Test-Tools dabei zum Einsatz kommen, hängt von der Anwendung ab. Mit Newman lassen sich öffentliche API-Methoden unkompliziert testen, JUnit, Xunit oder Jest eignen sich hervorragend für Unit-Tests von Code und Komponenten, und Playwright oder Cypress sind ideal für vollständige End-to-End-Tests bis auf UI-Ebene, sofern Ihre Anwendung eine Web-Anwendung ist.
Die Test-Phase ist außerdem der richtige Ort, um Test-Management-Tools wie TestRail einzubinden. Solche Tools erstellen umfassende Reports zur Codebasis und zu den Testergebnissen und geben Stakeholdern Einblick in den Entwicklungszyklus und den Reifegrad der Anwendung. So entstehen aussagekräftige Berichte für Ihre Stakeholder, die zeigen, wo das Unternehmen in Sachen Entwicklung und Anwendungsreife steht. Entscheidend ist dabei ein Mindset-Wandel: Qualität ist überall im Unternehmen verankert – nicht nur innerhalb einer QA-Abteilung. Diese Haltung führt zu den besten Ergebnissen, und die Test-Phase ebnet Ihnen den Weg dorthin.
Warum die Test-Phase so wichtig ist
Der wichtigste Vorteil der Test-Phase: Tests, Qualitätssicherung und Performance-Bewertung finden so früh wie möglich im SDLC statt. Dieser Shift-Left-Ansatz unterscheidet sich klar vom traditionellen oder manuellen Testen, das meist erst am Ende des Zyklus ansetzt.
Einige offensichtliche Vorteile der Test-Phase:
- Tests früh im SDLC zu verankern, ermöglicht einen kontinuierlichen Testprozess und damit eine schnellere, fortlaufende Auslieferung von Software. Dieser Ansatz unterstützt schnelles, häufiges und frühes Testen und verringert das Risiko, dass Fehler unentdeckt bleiben.
- Automatisiertes Testen schaltet den menschlichen Faktor aus, der Fehler übersieht – allerdings müssen die Testszenarien dafür gepflegt und aktualisiert werden. Unter Umständen braucht es deshalb ein eigenes Team aus Software-Entwicklern, die sich auf Tests spezialisieren.
- Jede Phase des SDLC bringt unterschiedliche Testformen mit sich (Unit-Testing, API-Testing, E2E- und UI-Testing). Das hält den Aufwand gering, falls ein Fehler zurückverfolgt werden muss.
Wer diese Phase einführt, verkürzt die Time-to-Delivery, reduziert Fehler und Bugs und etabliert ein Modell der geteilten Qualitätsverantwortung, in dem die gesamte Engineering-Abteilung für die Qualität der Anwendung einsteht.
Über die Test-Pyramide
Die Test-Pyramide ist ein bekanntes Konzept der Softwareentwicklung und wurde in zahlreichen Artikeln und Publikationen behandelt. Die ursprüngliche Beschreibung stammt von Mike Cohn in seinem Buch Succeeding with Agile. Die Pyramiden-Metapher hilft dabei, die verschiedenen Testebenen zu visualisieren, die in der Softwareentwicklung umgesetzt werden sollten.
Behavior-Driven Tests sind besonders wirkungsvoll, weil sie Testszenarien und erwartete Ergebnisse abbilden. Sie decken die Integration zwischen Komponenten ab – und genau deshalb sind Integrationstests so wertvoll: Sie prüfen das System als Ganzes oder in isolierten, komplexen Modulen, statt nur einzelne Einheiten. Auf den ersten Blick klingt es deshalb verlockend, vor allem in UI-E2E-Tests zu investieren, die nach dem Deployment auf das vollständig integrierte System angewandt werden – und das ist auch nicht falsch. Allerdings gibt es Fallstricke: Wer ausschließlich auf UI-E2E-Tests setzt, riskiert unverhältnismäßige Kosten, hohen Wartungsaufwand und Frust.
Wer ausschließlich in UI-End-to-End-Tests investiert, landet schnell beim "Ice-Cream-Cone"-Anti-Pattern in der Test-Pyramide – auch bekannt als atypische oder umgekehrte Test-Pyramide.
Die Wartung dieses Kegels wird zum Albtraum, die Kosten geraten außer Kontrolle, die Testergebnisse werden inkonsistent – und Ihr Unternehmen verliert die Vorteile einer sauber aufgesetzten Test-Phase.
Schauen wir uns nun die Ebenen der Test-Pyramide, die gängigen Testarten und ihre jeweiligen Vorteile an.
- Unit-Tests: die grundlegendsten und feingranularsten Tests. Sie konzentrieren sich auf eine einzelne Arbeitseinheit – meist eine Methode oder Komponente. Sie bilden die Basis der Test-Pyramide und lassen sich in der Build-Stage kompilieren und ausführen. Sie sind einfach umzusetzen, kostengünstig und bieten eine erste Verteidigungslinie für die Code-Qualität.
- Integrationstests/API-Tests: Da die Integration über die API erfolgt, ist das Testen dieser Ebene für Ihre Systeme entscheidend. Diese Tests müssen sicherstellen, dass das System im Zusammenspiel funktioniert (also dass die einzelnen Arbeitseinheiten auch in ihrer Integration miteinander bestehen können). Je nach Organisationsstruktur werden sie von Entwicklern oder Quality-Spezialisten umgesetzt. Letztlich möchte niemand in ein Flugzeug einsteigen, das nur per Unit-Test geprüft wurde.
Test-Automatisierung ist…
Wenn Ihr Software-Bestand stetig wächst – oder selbst wenn er weitgehend statisch ist –, wird das manuelle Testen Ihrer Anwendung schnell zur Mammutaufgabe. Repetitive Prozesse zuverlässig durchzuführen und gleichzeitig den menschlichen Fehlerfaktor klein zu halten, ist manuell kaum machbar. Genau hier kommt die Automatisierung ins Spiel. Sie ist heute in nahezu allen Bereichen Standard – von der Infrastruktur über die Orchestrierung von Builds bis hin zum Testen von Code und Anwendungen.
In der Praxis heißt das: Entwickler kümmern sich im Rahmen ihrer Deliverables um Unit- und Integrationstests, während Quality-Spezialisten die UI-E2E-Tests auf Basis der Szenarien von Business- oder Product-Ownern schreiben. Die Test-Discovery-Phase – meist manuell durchgeführt – findet als Vorbereitungsschritt vor der Automatisierung statt.
Für die Automatisierung der Test-Phase gibt es heute zahllose Tools auf dem Markt. Die Möglichkeiten sind nahezu unbegrenzt und hängen vor allem von Ihren Anforderungen und den Skills Ihrer Entwicklungsorganisation ab. Playwright und Cypress unterstützen Sie bei UI-E2E-Tests; beide Tools haben Vor- und Nachteile, und inzwischen lassen sie sich sogar als One-Stop-Shop für sämtliche Ebenen Ihrer Test-Pyramide einsetzen – etwa wenn Ihr Stack auf JavaScript basiert. Auch auf der Integrationsebene ist die Auswahl groß: Katalon, Newman von Postman und viele weitere. Prüfen Sie immer die Features und berücksichtigen Sie Komplexität, Interoperabilität und Integrationsfähigkeit in eine CI/CD-Pipeline – schließlich ist genau das der Sinn dieser Tools: sie in Ihre Test-Phase und damit in Ihre CI/CD-Pipeline einzubinden. Bleibt zuletzt die Ebene der Unit-Tests: Hier sollten Sie die Tools wählen, die am besten zu Ihrer Codebasis passen – für .NET-Code etwa XUnit, für Java JUnit, für JS oder TS Jest. (Wie oben erwähnt sind moderne und vielseitige Tools wie Playwright bei JS- oder TS-Codebasen ebenfalls in der Lage, die gesamte Pyramide abzudecken. Werfen Sie hierzu bitte einen Blick in die offizielle Playwright-Dokumentation.)
AWS CodePipeline für Ihre Test-Phase
Die Test-Phase lässt sich mit verschiedenen Tools und Services umsetzen, die heute am Markt verfügbar sind. Mit Services wie Jenkins oder CircleCI durchlaufen Sie dieselben Schritte, um zum gewünschten Ergebnis zu kommen: Code aus dem Source-Repository ziehen > Code bauen > testen > in Pre-Production (Staging) deployen > optional erneut testen > in Production deployen. Fertig – das Deployment ist abgeschlossen.
Es gibt viele Tools und Services, doch werfen wir einen Blick auf die AWS-Services. AWS CodePipeline ist ein vollständig verwalteter Continuous-Delivery-Service (CD), mit dem sich Pipelines aufbauen, Stages orchestrieren und Updates für Anwendung und Infrastruktur ausliefern lassen. AWS CodePipeline arbeitet hervorragend mit anderen AWS-DevOps-Services wie AWS CodeDeploy, AWS CodeCommit und AWS CodeBuild zusammen – sowie mit bekannten Drittanbietern wie Jenkins und Github.
Ein einfacher Anwendungsfall für die Pipeline lautet: Code ziehen > bauen > deployen. Das wirkt simpel – und in diesem Fall können Sie nur Unit-Tests in der Build-Stage der Pipeline ausführen. Soweit, so gut. Aber was, wenn Sie eine komplexere Pipeline möchten, deren Test-Phase auch Integrationstests und sogar UI-E2E-Tests umfasst? Dann sieht die Pipeline so aus: Code ziehen > bauen > nach Staging deployen > testen > nach Prod deployen. Der Unterschied: Wir erweitern die Pipeline um eine Test-Stage, in der Integrations- und/oder UI-E2E-Tests gegen die zuvor deployte Staging-Umgebung laufen. Das ist deutlich besser! Die Test-Phase einzubauen, ist denkbar einfach: Über die Edit-Seite der bestehenden Pipeline fügen Sie einen zusätzlichen Schritt (Stage) hinzu und konfigurieren die Test-Ausführung über das native Test-Framework (abhängig vom eingesetzten Test-Tool).
Da dieser Service vielseitig ist und mit zahlreichen weiteren AWS- und Drittanbieter-Services zusammenarbeitet, ist es schwer, ein einzelnes Beispiel herauszugreifen. Einige nützliche und wichtige Funktionen von AWS CodePipeline sollten dennoch erwähnt werden:
Detection Option: eine Eigenschaft der Pipeline, die diese startet. Abhängig vom Speicherort der Artefakte empfiehlt AWS Github-Webhooks für Github bzw. Amazon CloudWatch Events für Artefakte, die etwa in einem AWS-S3-Bucket liegen.
Disable/Enable Transition: Die Transition verbindet die Stages der Pipeline und ist standardmäßig aktiviert. Falls Sie nicht automatisch von einer Stage zur nächsten übergehen möchten, deaktivieren Sie sie über den Button "Disable Transition" und unterbinden so die kontinuierliche Ausführung der Pipeline. Das erneute Aktivieren ist genauso unkompliziert.
Add Stage: Um die Reihenfolge der Pipeline zu ändern und neue Stages einzufügen oder bestehende zu entfernen bzw. zu aktualisieren, klicken Sie auf "Edit". Auf der Edit-Seite können Sie Aktionen seriell oder parallel zu bestehenden Aktionen hinzufügen. Diese Funktion macht Ihre Pipeline flexibel und erweiterbar.
Approval Action: Wenn Sie die Stages Ihrer Pipeline aktiv steuern möchten – etwa um eine Deploy-Stage manuell freigeben zu lassen –, nutzen Sie diese Funktion. Sie pausiert die Pipeline bis zur Freigabe und setzt die Ausführung danach fort.
Weitere DevOps-AWS-Services, mit denen CodePipeline gut zusammenspielt:
- AWS CodeCommit
- AWS CodeDeploy
- AWS CodeBuild
Zusammenfassung und Fazit
Keine Pipeline sollte ohne Test-Phase auskommen – und kein Release ohne Test-Phase ausgeliefert werden. Den menschlichen Faktor minimieren, auf Automatisierung und die verfügbaren Tools setzen: Genau das sollte der Fokus der für CI/CD verantwortlichen DevOps-Spezialisten sein. Doch nicht nur die DevOps-Spezialisten, die die Pipeline aufsetzen, sind gefragt – die gesamte Entwicklungsorganisation, also Developer, QA-Personal und das DevOps-Team, sollte Qualität als gemeinsame Verantwortung verstehen und die Test-Phase als verfügbare, komfortable, flexible und absolut belastbare Komponente begreifen. Der Einsatz eines passenden Services wie AWS CodePipeline hilft Ihnen, genau diese Ergebnisse zu erzielen!
Links und Ressourcen: