Testen als Prozessbegleitung
Während im traditionellen Software Entwicklungsprozess „Test“ als eigene Phase geplant, vorbereitet, durchgeführt und evaluiert wird, beschreibt „Continuous Testing“ die Vorgehensweise, bei der das Testen den kompletten Prozess begleitet mit dem Ziel, Risiken zum ehest möglichen Zeitpunkt aufzudecken.
Wesentliche Merkmale des Continuous Testing sind:
- Hoher Automatisierungsgrad
- Klare Zuordnung von (fehlgeschlagenen) Tests zu Geschäftsrisiken
Im Idealfall umfasst Continuous Testing sowohl funktionale, als auch nicht-funktionale Tests (Security-Tests, Performance-Tests, etc.).
Um Continuous Testing umzusetzen, betrachten wir die verschiedenen Ausbaustufen im Software Entwicklungsprozess.
Testing & Continuous Integration
Der Begriff Continuous Integration (CI) wurde 1991 von Grady Booch geprägt. Gemeint ist die kontinuierliche Integration aller Entwicklungstätigkeiten in den “main branch”. Über diese Maßnahme wird die zeitaufwändige Integration unterschiedlicher Komponenten in kleineren Inkrementen vorgenommen. Dadurch werden “breaking changes” früher erkannt und können leichter auf spezifische Änderungen zurückgeführt und entsprechend behandelt werden.
Qualitätssichernde Maßnahmen in der Continuous Integration sind vor allem
- Statische Codeanalyse sowie
- Unit Tests,
die im Rahmen des Builds vom CI Server durchgeführt werden.
Häufig wird mit Vorgaben zur Code Coverage der Unit Tests gearbeitet. Was auf den ersten Blick wie eine gute Idee erscheinen mag, kann sich schnell ins Gegenteil verkehren: Die Erhöhung der Coverage stellt mit den Mitteln der meisten modernen Entwicklungsumgebungen (IDEs) keine große Herausforderung dar, das Erzwingen führt aber schnell zu einer Verschiebung von Qualität zu Quantität. Zielführender ist es, im Rahmen von Workshops, Schulungen oder Pair Programming Sessions die Achtsamkeit des Entwicklungsteams für Qualitätsmerkmale von Unit Tests zu erhöhen.
Anzeichen für Verbesserungspotential im Unit Test Bereich sind u.a.:
- Testergebnisse der Unit Tests sind nicht, oder nur schwer verfügbar.
- Unit Tests, die nur lokal, nicht aber am Build Server ausgeführt werden (können).
- Commits zu neuen Features, ohne zugehörige Unit Tests.
Testing & Continuous Delivery
Während Continuous Integration bei einem getesteten Artefakt in einem Repository endet, umfasst Continuous Delivery auch die nächsten Schritte, nämlich die Software automatisiert in verschiedenen Umgebungen („Stages“) in Betrieb zu nehmen und zu testen.
Nach dem Motto: “If it hurts, do it more often”, werden dabei die häufig aufwändigen Schritte der Installation und Konfiguration formalisiert und in automatisiert reproduzierbare Form gebracht.
Die Schlagworte dazu sind „Configuration as Code“ und „Infrastructure as Code“, wobei in einer Cloud Umgebung auch das komplette Provisioning einer Umgebung automatisiert erfolgen kann.
In der Continuous Delivery Pipeline durchwandert das Artefakt die verschiedenen Stages, wobei jeweils der Umgebung angepasste Tests automatisiert durchgeführt werden. Nachdem immer nur kleine Inkremente getestet werden, können Probleme meist gut auf spezifische Änderungen zurückgeführt werden. Sollten die Tests in einer Stage fehlschlagen, wird die Pipeline abgebrochen; die Anzahl der Stages richtet sich stark nach den verschiedenen Arten von Integrationstests, die ausgeführt werden.
Häufig werden zumindest folgende Stationen geplant:
- Development: Test der einzelnen Artefakte, Integration mit Infrastruktur
- System Test: Integration aller Artefakte innerhalb der Systemgrenzen, automatisierte System Tests, umgebende Systeme werden ge-mocked oder virtualisiert bereitgestellt
- System Integration Test: Umgebung mit Anbindung der umgebenden Systeme, automatisierte End-to-End Tests
- User Acceptance Test: Umgebung mit Anbindung der umgebenden Systeme, in produktionsnaher Ausführung (Konfiguration und Skalierung); Verwendung für Abnahmetests (auch manuell), gegebenenfalls Last- und Performance Tests
Testing & Continuous Deployment
Als Erweiterung zur Continuous Delivery umfasst Continuous Deployment zusätzlich das automatisierte Deployment jeder abgenommenen Erweiterung in Produktion.
Das ermöglicht eine starke Verkürzung der „time-to-market“, und frühes Feedback der Kunden. Bei sorgsamem Einsatz von Test entlang der Pipeline werden wenige Software Fehler in Produktion „entlassen“, und die, die bis dahin nicht aufgedeckt wurden, können schnell behoben werden, weil immer nur kleine Änderungen betroffen sind.
Testmaßnahmen, die Continuous Deployment unterstützen sind
- Tests in Produktion: Tests in Produktion umfassen ein reduziertes Test Set, das nach jedem Deployment ausgeführt wird. Tests in Produktion erfordern frühzeitige Planung, mit besonderer Berücksichtigung des Umgangs mit Test Daten und gegebenenfalls Autorisierungs-/Authentifizierungsabläufen.
- Health Checks: Automatisierte Tests von kleinen Flows (z.B. Login), die periodisch durchgeführt werden.
- A/B Tests (vor allem in Webanwendungen): Neue Änderungen werden zunächst einer kleineren Gruppe bereitgestellt, erst nach Auswertung von Metriken wird entschieden, welche Variante übernommen wird.
