Kurze Releasezyklen in der SAP Entwicklung? Automatisierte Tests machen’s möglich!
Um hohen Fehleraufkommen in Neuentwicklungen nach der Produktivsetzung vorzubeugen, können Sie umfangreiche, tiefgehende Tests durchführen. Der zusätzliche (Zeit-)Aufwand macht sich jedoch stark in den Kosten bemerkbar. Um diese Fixkosten auszugleichen, sammeln viele Unternehmen zunächst Entwicklungen, testen diese dann gemeinsam in weiten Zyklen und setzen sie erst dann produktiv. Braucht es also umfangreiche und zeitintensive Releasezyklen? Die kurze Antwort: Nein. Wie automatische Tests Abhilfe schaffen, lesen Sie in diesem Blog.
Vor ein paar Tagen las ich einen Blogartikel, der mit einer Grafik aus einer Studie von 1991 daherkam. Die Studie setzte sich mit Reparatur- und Renovierungsarbeiten an Wohnungseinheiten auseinander. Die Grafik selbst verglich drei mögliche Zeitpunkte, an denen die Reparaturen vorgenommen werden können:
- Wenn es größere Ausfälle gibt, was oft in großen Reparaturen endet
- Früher, wenn es kleinere Ausfälle gibt. Dementsprechend kleiner sind auch die Reparaturen
- Möglichst früh, um normale Abnutzung der Einheit auszugleichen
Die Grafik sah ungefähr so aus:
Instanthaltungskosten einer Wohneitheit bei verschiedenen Reparaturintervallen
Kleinere Reparaturen werden häufiger durchgeführt und bringen damit in Summe mehr Fixkosten mit sich. Ein Termin muss vereinbart werden, das Reparaturteam muss anreisen, Rechnungen sind zu verarbeiten. Dennoch rechnen sich die häufigeren Reparaturen. Warum?
Abnutzung an einer Wohneinheit verläuft nicht linear. Die verschiedenen Stellen interagieren miteinander und sorgen so dafür, dass der Verschleiß exponentiell zunimmt. Dieser Effekt ist groß genug, um die zusätzlichen Fixkosten problemlos zu überdecken.
Ob Hausrenovierung oder Softwareentwicklung: Bündle nur, was vom Bündeln profitiert
Eine ähnlichen Effekt sehen wir in der Softwareentwicklung. Änderungen im System beeinflussen einander, auch wenn das nicht vorgesehen ist. Diese unerwünschten Nebeneffekte sind oft gut versteckt und werden für Sie erst ersichtlich, wenn Sie auch außerhalb des Entwicklungsrahmens testen.
Die offensichtliche Lösung sind umfassende, tiefgehende Tests, bevor eine Entwicklung produktiv gesetzt wird. Dadurch können Sie versteckte Zusammenhänge und Fehler aufdecken – aber der zusätzliche Aufwand macht sich in den Kosten bemerkbar. Um diese Fixkosten auszugleichen, sammeln viele Unternehmen zunächst Entwicklungen, testen diese dann gemeinsam in weiten Zyklen und setzen sie erst dann produktiv.
Mit größeren Releases kommen stärkere, häufigere Interaktionen zwischen den Entwicklungen, die erkannt und behoben werden müssen. Die exponentielle Natur dieser Zusammenhänge macht sich hier wieder stark bemerkbar. Doch mit genug Testaufwand können Sie dies im Zaum halten.
Hier bleibt nun die Frage: „Sind wir in der Softwareentwicklung dazu verdammt, seltene und große Releases zu fahren?“
Automatische Tests: Fixkosten minimieren – Release-Zyklen verkürzen
Einen gigantischen Anteil der Kosten eines Releases – neben der Entwicklung selbst – macht das Testen aus. Optimalerweise prüfen Sie dabei jeden Prozess, jede Abweichung und Sonderregelung auf Funktionalität. Falls diese Aufgabe auf den Fachbereich fällt, muss dieser zusätzlich zum Tagesgeschäft funktionale Tests ausführen, die nicht direkt mit den angeforderten Änderungen zusammenhängen.
Abhilfe schaffen automatische Tests, beispielsweise mit ABAP Unit und dem SAP Solution Manager. Ähnlich wie ein Prozess- oder Testkatalog wird ein automatisierter Testablauf einmal initial aufgestellt. Danach führt sich der Test jedoch automatisch aus, und das innerhalb kürzester Zeit und ohne weitere Eingaben. Der automatisierte Testablauf prüft seltene Konstellationen und Sonderfälle bei jedem Durchgang. Damit stellen Sie sicher, dass auch jährliche Prozesse nicht beeinträchtigt werden.
Auch das frühere Erkennen der Fehler spart unnötige Kosten: Die Kosten für die Fehlerbehebung steigen, je später Sie ihn im Softwareentwicklungsprozess erkennen. Dieser Zusammenhang wurde mehrfach festgestellt, ich beziehe mich dabei gerne auf Applied Software Measurement von Capers Jones. Der Graph zeigt, wie viele Fehler durch das automatische Testen schon früh abgefangen werden. Fehlt dieser Schritt, fallen diese stattdessen im Feldtest oder erst nach dem Release auf.
Kostendarstellung bei der Fehlerbehebung im Verhältnis zum Zeitpunkt, zu dem Sie ihn entdecken
Mit minimierten Fixkosten werden somit auch kleinere Releases immer lukrativer. Da sich die Testbibliothek durchgehend erweitert, sinkt die Wahrscheinlichkeit, einen Sonderfall übersehen zu haben. Der Testaufwand erhöht sich dabei nicht. Gleichzeitig fungieren die Tests als Dokumentation des erwarteten Systemverhaltens, ohne veralten zu können.
Automatische Tests machen tägliche Releases möglich und garantieren Ihnen zugleich ein stabiles System.
Glückliche Nutzer, Entwickler und Manager
Der Begleittext zu der oben referenzierten Grafik bei den Renovierungsarbeiten an Wohnungseinheiten erwähnte noch einen nicht gemessenen, aber wichtigen Faktor der Instandhaltung einer Wohneinheit: Ein Gebäude, das durchgehend verfällt oder droht zu verfallen, hat eine negative Auswirkung auf seine Bewohner. Und das bringt eine weitere Dimension zu den anfallenden Kosten.
Große, seltene Releases in einem System unterbrechen den gewohnten Arbeitsfluss. Unerwartete Fehler durch versteckte Abhängigkeiten destabilisieren das System und verringern das Vertrauen der Nutzer – sowohl in die Fähigkeiten der IT als auch in das System, mit dem sie täglich interagieren. Auch die langen Entwicklungszyklen für neue Funktionalitäten sind nicht nur ein Kostenfaktor, sondern wirken sich negativ auf die Zufriedenheit der Nutzer aus. Die tatsächlichen Kosten sind nur sehr schwer zu ermitteln, aber das macht sie nicht weniger relevant.
Automatisierte Tests helfen Ihnen also dabei, das System zu stabilisieren und sorgen für weniger unangenehme Überraschungen. Zugleich sind kleinere Releases deutlich übersichtlicher und angenehmer. Sie könenn neue Anforderungen schnell umsetzen und produktiv schalten, ohne davon unabhängige Prozesse zu beeinflussen.
Nächster Halt: Continuous Integration?
Automatische Tests sind in der Softwareentwicklung nichts Neues. Gerade außerhalb der SAP-Blase haben sich die Entwicklungsprozesse noch weiterentwickelt und implementieren die kontinuierliche Integration (Continuous Integration oder CI) neuer Entwicklungen. Dies umfasst das automatische Zusammenfügen individueller Entwicklungen und das darauf folgende Testen des neuen Systemstandes. Misslingt ein Test, baut das System die neue, fehlerhafte Entwicklung automatisch wieder aus und benachrichtigt den Entwickler. Damit bleibt das Testsystem immer sauber und kann weiterhin unabhängige Tests garantieren.
Noch weiter treiben es Continuous Deliver und Continuous Deployment, welche den gesamten Prozess von Abschluss den Entwicklung bis zur Bereitstellung oder sogar Einspielung des Releases automatisieren. Beispiele hierfür sind bekannte Größen wie Amazon, Netflix und Walmart, aber auch viele Open-Source-Projekte.
Diese Prozesse sind für Entwicklungsumgebungen geschaffen, die von den meisten SAP Systemlandschaften abweichen. Diese Prozesse in SAP einzubinden ist also komplizierter als ein direkter Transfer und mit dem Aufarbeiten der hinterliegenden Grundsätze verbunden. Allerdings hat SAP in den letzten Jahren viel auf den Ausbau und die Stärkung von modernen Entwicklungsprozessen gesetzt. Project Piper und das git-enabled Change and Transport System sind erste, große, Schritte die die Entwicklung in ABAP auf eine Ebene mit der Entwicklung in anderen Systemen bringen können.
Haben Sie noch Fragen zum automatisierten Testmanagement ? Hinterlassen Sie gerne einen Kommentar oder sprechen Sie mich an, ich freue mich auf den Austausch!
