Africa Studio - stock.adobe.com
Weniger Entwicklungsrisiken durch Continuous Testing
Kontinuierliches Testen lässt sich in sieben Schritten erfolgreich umsetzen. Wie man Ziele identifiziert und Fehler durch kontinuierliche Prozesse vermeidet.
Stellen Sie sich ein Szenario vor, in dem Ihr Entwicklungsteam bei jeder Änderung einen neuen Build erstellt, 100 Testumgebungen in der Cloud anlegt und die Software 100 gleichzeitige Simulationen durchläuft. Und das alles in weniger als zwei Minuten.
Continuous Testing (kontinuierliches Testen) macht genau das möglich und eliminiert den Regressionstestzyklus fast vollständig – es sei denn, der zu testende Code ist nicht optimiert. Wenn Programmierer zu einer schlechten Codebasis beitragen, ist die Hauptverzögerung nicht der Test, sondern der Fix. Nach jedem Soforttest muss das Team Berichte durchgehen, Probleme reproduzieren, sicherstellen, dass das gefundene Problem die Ursache und nicht ein Symptom ist, einen Fix erstellen und erneut testen.
Ein Programm für kontinuierliches Testen setzt eine hohe Ausgangsqualität und eine niedrige Rate an Regressionsfehlern voraus. Es sollte außerdem in einem föderierten Modell funktionieren, in dem die Änderungen im Subsystem isoliert sind, so dass diese nicht das Gesamtprodukt manipulieren.
Es gibt mehrere Best Practices, die besseres Continuous Testing ermöglichen. Folgende sieben Schritte des Continuous Testing betreffen hauptsächlich Web- und Mobile-Anwendungen.
1. Alle Pfade vor dem Zusammenführen testen
Zusätzlich zu den Tools und der Automatisierung gibt es viele Tests, die nur einmal ausgeführt werden müssen. Exploration ist Teil des Entwicklungsprozesses. Testen Sie erst jede Funktion einzeln und geben Sie anschließend grünes Licht für den gesamten Pfad. Damit verhindern Sie langwierige Analyse/Debug/Fix-Zyklen auf höheren Ebenen. Schäden und defekte Builds, die durch das Zusammenführen entstehen, können mit modernen Merge Tools, wie zum Beispiel Git, auf ein Minimum reduziert werden.
2. Die Business-Logik-API vom Frontend trennen
Eine der einfachsten Möglichkeiten, wiederverwendbare Komponenten zu erstellen, ist die Trennung von GUI und API. Dadurch ist es möglich, jeweils nur eine API einzusetzen oder nur ein Element der GUI zu ändern. Diese klare Trennung zwischen den Services verringert die Wahrscheinlichkeit, dass eine Änderung in einem Teil der Anwendung einen anderen unterbricht.
3. Die Business-Logik auf API-Ebene testen
Da die API von der GUI getrennt ist, ist es möglich, sie zu testen. Ohne GUI sind automatisierte API-Prüfungen in der Regel viel schneller, einfacher zu debuggen und es ist unwahrscheinlicher, dass sie aufgrund von Änderungen fehlschlagen. Sie werden in der Regel als Funktionen mit bekannten Eingaben und erwarteten Ergebnissen implementiert, so dass der Tester einen einzelnen Test über Dutzende von Beispielen ausführen kann, die als Daten gespeichert sind.
Wenn eine Änderung innerhalb der Grenzen einer einzelnen API stattfindet, dienen diese Tests als Vereinbarung, dass die Änderung nicht das Verhalten der API für andere Programme beeinträchtigt. Sobald die Geschäftslogik-Kombinationen auf API-Ebene abgedeckt sind, kann sich die verbleibende End-to-End-Automatisierung auf den Benutzerstrom konzentrieren, anstatt auf eine mögliche Explosion von Werteingaben.
4. Die Zeiten für Fehleridentifikation und Recovery verbessern
Die eigentliche Herausforderung beim kontinuierlichen Testen besteht darin, die Testszenarien auf wenige, leistungsstarke zu beschränken. Tests sind keine Masseninspektion und die Änderungsgeschwindigkeit bei den Prozessen bedeutet, dass sich Fehler einschleichen können. Effektives Continuous Testing und Deployment kann dazu führen, dass ein Team Fehler in der Produktionsumgebung in weniger als einer Stunde beheben kann. Wogegen beim alten Feedback-Zyklus die Behebung von einem Fehler in der Produktion Wochen oder gar Monate dauerte. Wenn ein Fehler innerhalb einer Stunde nach dem Go-Live gefunden wird, wird seine Wirkung um den Faktor 40 reduziert.
Eine gängige Methode zur Verkürzung der Zeit bis zur Fehlererkennung ist die Überwachung der Produktion auf, wie zum Beispiel nicht gefundene Seiten, unbehandelte Ausnahmen und lange Render-Zeiten für die Seiten. Eine ausgefeilte Überwachungssoftware kann herausfinden, wo im Workflow ein Benutzer einen Anwendungsfall aufgibt. Der Verzicht auf den Checkout-Prozess eines E-Commerce-Shops senkt den Umsatz zum Beispiel direkt um höhere Prozentsätze.
5. Feature Toggles in der Produktion verwenden
Eine weitere Art, das Risiko zu reduzieren und Continuous Testing zu verbessern, ist die Möglichkeit, neue Funktionen auszuschalten, wenn sie unbeliebt oder fehleranfällig sind. Zum Beispiel wird ein neuer Menüpunkt in eine if-Anweisung eingeschlossen, wobei die if-Anweisung eine einzelne Datei auf der Festplatte auf einen Schlüssel prüft. Das Programm benötigt keine Neukompilierung, einen kontinuierlichen Integrationsablauf oder ein Redeployment, um diese Datei zu ändern. Stattdessen ändert der Programmierer die Datei, aktualisiert die Versionskontrolle und startet das Ganze, und die Funktion schaltet sich aus. Sobald das Problem identifiziert wurde, verringert sich die erwartete Wiederherstellungszeit von einer Stunde auf einige Minuten. Man sollte dieses Feature Toggle mit der Komponentenbereitstellung kombinieren, um den Entwicklungsteams mehr Möglichkeiten zur schnellen Problemlösung zu geben.
6. An jedem Feature vor und während der Entwicklung zusammenarbeiten
Um die Chancen zu erhöhen, dass das neue Produkt auf Anhieb akzeptiert wird, sollte man genau herausfinden, was das neue Feature genau erreichen soll – und zwar nicht nur im Voraus, sondern auch kontinuierlich während der Entwicklungsphase. Ohne genau zu wissen, wie das Produkt in der Produktion funktionieren soll, wird die Software das Falsche machen. Wenn der Kunde die Annahmen, die einem Feature zugrunde liegen, als falsch deklariert, müssen der Programmcode und die Test-Tools nachgearbeitet werden, was den Aufwand verdoppelt. Die Überarbeitung geht davon aus, dass Entwickler und Tester während der Programmierphase miteinander gesprochen haben. Ohne Kommunikation muss es einen zusätzlichen Feedback-Schritt geben, bei dem der Tester den Programmierer dahingehend korrigiert, was die Software tun soll.
7. Codierung als Handwerk
Code, der ohne klare Ziele geschrieben wird, ist schwer zu entwickeln. Kontinuierliches Testen impliziert einen kontinuierlichen Prozess, bei dem der Code fortlaufend geringfügig in die eine oder andere Richtung hin erweitert wird. Teams, die ständig kleine Änderungen vornehmen möchten, werden die Kunst eines sauberen Ablaufs studieren wollen, besonders was Softwareprofi Robert Martin in seinem Buch Clean Code dazu schreibt.
Steve McConnell, Autor mehrerer Softwareentwicklungs-Bücher, erklärt in Code Complete, wenn das Schreiben guter Software wie Abnehmen ist, dann ist Softwaretesten der Moment, wenn man sich auf die Waage stellt. Dies zeigt einem, wo man steht. Aber um Pfunde zu verlieren, muss man Diät halten und sich bewegen.
Kontinuierliches Testen ermöglicht häufigere Releases und hilft bei der Suche von Problemen. Wenn man nicht besser entwickelt, bleiben die Probleme bestehen, was Überlastungen, Nachbearbeitung und Verzögerungen verursacht. Sauberer Code, Komponentensoftware, die die API von der GUI trennt, Feature Toggles und Monitoring sind zwar nicht unbedingt Teil von Continuous Testing, aber sie tragen zum Erfolg bei.
Folgen Sie SearchEnterpriseSoftware.de auch auf Twitter, Google+, Xing und Facebook!
