Continuous Testing

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:

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

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.:

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:

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

Scroll to Top