Gespart – ein Softwareleben lang

Automatisierte Testabsicherung

Um einen hohen Qualitätsstandard halten zu können, sind Tests unverzichtbar. Eine Weisheit, die über die verschiedenen Etagen in einem Unternehmen hinweg hinreichend bekannt ist. Aber warum ist das eigentlich so? Die naheliegende Antwort auf diese Frage ist, dass z. B. mit Unit Tests sichergestellt werden kann, dass die einzelnen Softwarekomponenten sich wie erwartet verhalten. Das stimmt so weit, aber eine hohe Testabdeckung bietet noch viel mehr: Flexibilität. Sie ermöglicht es einem Entwicklerteam, ohne Skrupel die Struktur einer Software zu ändern, um entsprechend dynamisch auf neue oder ggf. geänderte Anforderungen reagieren und eingehen zu können. Gleichermaßen forsch dürfen Manager und Architekten erwarten, dass das möglich ist.

Einem automatisierten Build nachgelagerte Integrationstests stellen sicher, dass alle Architekturschichten tadellos miteinander harmonieren. Man kann sagen, sie bilden die zweite Linie auf dem Schlachtfeld gegen die schier unendlich große Armee von Bugs. Auch hier gilt wie schon bei den Unit Tests: viel hilft viel. Nicht selten decken solche Tests Fehler in den Bibliotheken von Drittanbietern auf. Mit dieser Erkenntnis können Workarounds geschaffen werden – ein notwendiges Übel in einer nicht perfekten Welt. Daneben können mit Performancetests Softwaresysteme an ihre Grenzen gebracht werden. Eine Analyse der Ergebnisse gibt Aufschluss darüber, ob ein System einen hohen Grad an Skalierbarkeit aufweist. Da solche Tests sehr aufwändig in Bezug auf Reproduzierbarkeit sind (insbesondere sinnvolle Datenbestände für die unterschiedlichen Versionen einer Software sind ein immenser Kostenfaktor), sollte immer abgewogen werden, inwieweit sie notwendig sind.

User Acceptance Tests (UAT) hingegen sind immer notwendig. Sie stellen sicher, dass Software von den Benutzern – wie der Name schon sagt – akzeptiert wird, d. h., die abgebildeten Geschäftsprozesse müssen zugänglich und intuitiv sein. Dass die Geschäftsprozesse über die Oberfläche zugänglich sind, kann automatisiert getestet werden, was natürlich zu einer Kostensenkung führt. Damit ist aber noch nicht sichergestellt, dass Benutzer deren Abbildung auch verstehen. Hier kommen manuelle Tests ins Spiel. Die Aufgabe der Tester an dieser Stelle ist es, festzustellen, ob die Abbildung der Geschäftsprozesse den Anforderungen der Benutzer genügt – sie sollten im optimalen Fall keine technischen Fehler mehr feststellen können. Das erhöht noch einmal die Gesamtqualität von Software und resultiert in einem nicht quantifizierbaren Mehrwert, denn zufriedene Kunden werden durch Mund-zu-Mund-Propaganda für Gratiswerbung sorgen.

Delivery Pipeline

Alles in allem sollten die angesprochenen Punkte miteinander harmonisiert werden. Sie zusammen ergeben die Rohstoffe für eine so genannte „Delivery Pipeline“, in Abbildung 1 exemplarisch dargestellt.

Abb. 1: Delivery PipelineAbb. 1: Delivery Pipeline (Vergrößern)

Die Grafik verdeutlicht in groben Zügen das Zusammenspiel der bereits erwähnten Themengebiete, auf technische Details haben wir bewusst verzichtet. Es ist klar erkennbar, dass der Großteil eines Softwareauslieferungsprozesses automatisiert werden kann. Aufbauend auf SCM können automatisierte Builds mit nachgelagerten Tests geschaltet werden, deren Resultate als Grundlage für die Ermittlung von Qualitätsmetriken dienen. Manuelles Eingreifen wird erst dann notwendig, wenn der gesamte automatisierte Teil des Prozesses ausgeführt wurde. Hier kann entschieden werden, ob ein Release ausgeliefert werden soll oder nicht, denn erst dann lohnen sich weitere, kostenintensivere Prozessschritte, z. B. manuelle UAT. Das alles führt dazu, dass die laufenden Kosten bis zur Entscheidung – Release oder nicht – praktisch nur aus Stromverbrauch bestehen.

Kostenbetrachtung

Nachdem wir nun kurz umrissen haben, um was es bei den einzelnen Disziplinen inhaltlich geht und wie eine Delivery Pipeline aussieht, wenden wir uns der finanziellen Betrachtung zu. Hierfür nehmen wir ein fiktives Projekt zur Entwicklung eines Softwaresystems durchschnittlicher Größe an. Der Releasezyklus für das Projekt beträgt vier Wochen. Während eines solchen Zyklus‘ bauen und liefern die Entwickler die Software insgesamt durchschnittlich neunmal mit den hier angegebenen Aufwänden:

  • Sechsmal für eigene Tests auf die Testumgebung – 2 Stunden Aufwand je Lieferung
  • Zweimal für die fachlichen Tests auf die Abnahmeumgebung – 3 Stunden Aufwand je Lieferung
  • Einmal für den produktiven Betrieb – 5 Stunden Aufwand je Lieferung

Das ergibt einen Aufwand von 23 Stunden je Releasezyklus, wenn sämtliche Tätigkeiten manuell ausgeführt werden. Gehen wir davon aus, dass die Arbeitsstunde eines Entwicklers, der sich um diese Tätigkeiten kümmert, 50 € kostet, so landen wir bei Kosten von 1150 € je Releasezyklus. Automatisiert man die Tätigkeiten zum Bauen und zur Auslieferung der Software weitestgehend, so reduzieren sich Aufwand und Kosten drastisch. Das Bauen der Software und die Auslieferung auf die Testumgebung erfolgt dank der Delivery Pipeline vollständig automatisiert und kann sogar häufiger als die oben erwähnten sechs Mal erfolgen. Die Auslieferungen in Abnahme- und Produktivumgebung erfolgen zwar auf Knopfdruck automatisch, jedoch bleibt hier ein Restaufwand für organisatorische Abstimmungen. Manuelle Akzeptanztests fallen typischerweise nicht in den Tätigkeitsbereich der Entwickler und werden hier nicht betrachtet. Das führt bei unverändert neun Auslieferungen je Releasezyklus zu folgenden Aufwänden:

  • Beliebige Anzahl von Auslieferungen in die Testumgebung – 0 Stunden Aufwand
  • Zwei Auslieferungen in die Abnahmeumgebung – 1 Stunde Aufwand je Lieferung
  • Eine Auslieferung in den produktiven Betrieb – 2 Stunden Aufwand

In Summe ergibt das einen Aufwand von 4 Stunden und Kosten von 200 € je Releasezyklus. In vier Wochen sparen Sie also 950 € für dieses eine Projekt. Nun werden Sie vielleicht sagen: Ist ja schön und gut, aber die Tätigkeiten zu automatisieren, kostet initial erst einmal mehr Geld. Das können wir bestätigen. Aus der Erfahrung wissen wir, dass die Kosten hierfür bei ca. 10 000 € bis 15 000 € für durchschnittliche Projekte liegen. Hierfür wird die gesamte Infrastruktur für ein weitestgehend automatisiertes Build- und Release-Management mit integrierter Testausführung aufgebaut und konfiguriert. Daneben muss eine gute Dokumentation erstellt werden, damit Infrastruktur und Tools einfach zu nutzen, zu administrieren und zu erweitern sind.

Der Budgetverantwortliche für das eine Projekt wird jetzt wahrscheinlich sagen, dass sich das nicht rechnet. Da geben wir ihm erst einmal Recht. Um den Break Even zu erreichen – die 15 000 € einzusparen – müsste das Projekt über 16 Releasezyklen laufen, also 64 Wochen bzw. über ein Jahr (vgl. Abb. 2). Bis zu diesem Zeitpunkt wurde aber noch kein Cent gespart. Aus empirischen Untersuchungen, die z. B. in [2] und [3] zusammengefasst sind, ist bekannt, dass die Wartung von Software bis zu 80 % ihrer gesamten Kosten ausmacht, da sie in vergleichsweise kurzer Zeit erstellt wird und dann in eine lange Betriebs- und Wartungsphase geht. Das Projekt muss aus finanzieller Sicht kein Interesse an der Automatisierung haben. Der Betreiber der Applikation sollte es jedoch. Wir wollen an dieser Stelle nicht verschweigen, dass es Projekte gibt, die auf diese Automatisierung trotzdem Wert legen, da sie die Gewinne in Qualität und Schnelligkeit der Auslieferung mitnehmen wollen. Mit diesen Gewinnen lässt sich die Software ohne nennenswerten Mehraufwand häufiger ausliefern, was z. B. gerade bei agilen Projekten eine Anforderung ist.

Abb. 2: Amortisation mit einem Projekt/Produkt

Noch viel schneller rechnet sich die Automatisierung, wenn ein Unternehmen mehrere Softwareprodukte entwickelt und betreibt. Der größte Aufwand zur Automatisierung von Bau und Auslieferung der Software fällt typischerweise einmalig an, unabhängig davon, wie viele Projekte bzw. Produkte ein Unternehmen betreibt. Hat Ihr Unternehmen beispielsweise fünf Projekte/Produkte, sparte es mit einem automatisierten Build- und Release-Management knapp 5 000 € pro Releasezyklus, und der Break Even wird bereits nach 12 Wochen erreicht (vgl. Abb. 3).

Abb. 3: Amortisation mit fünf Projekten/Produkten
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.