Software-Deployment: Wann ist die Software wirklich bereit?

Software
(©Scott Graham / unsplash)

In der Software-Entwicklung laufen viele Prozesse äußerst strukturiert ab. Wenn es jedoch um das Deployment geht, scheiden sich die Geister und am Ende wird oft aus dem Bauch heraus entschieden. Hier gilt es mit System vorzugehen, um sowohl die Agilität als auch Qualität hochzuhalten.

Wie entscheidet sich, ob ein Software Release bereit für die Veröffentlichung ist? Würde man hundert Entwickler aus verschiedenen Branchen befragen, würde die Antwort mit hoher Wahrscheinlichkeit lauten: Wenn der Release “fertig” ist. Doch die Meinungen darüber, was “fertig” bedeutet, divergieren stark. Sie unterscheiden sich von Unternehmen zu Unternehmen und von Projekt zu Projekt. Nicht selten herrscht sogar innerhalb eines Teams Unstimmigkeit bei diesem Thema: Entscheidet der Projektmanager nach seinem Bauchgefühl? Gibt die Unternehmensstrategie den Ton an?

Jan Wolter, der Autor dieses Gastbeitrags, ist General Manager EU bei Applause (Bild: Applause).
Jan Wolter, der Autor dieses Gastbeitrags, ist General Manager EU bei Applause (Bild: Applause).

In der Regel gibt es unzählige Faktoren, welche die Entscheidung beeinflussen und oft spielt das Mindset und die Größe – beziehungsweise die Reife, sprich Maturity – des Unternehmens eine entscheidende Rolle. Kleinere Unternehmen und Start-ups tendieren eher dazu, Risiken einzugehen, Updates schnell zu veröffentlichen und auf das Feedback der Community beziehungsweise der Kunden zu reagieren. Etablierte Marktakteure und Konzerne hingegen setzen normalerweise auf gewachsene Prozesse und die Software Updates durchlaufen einen stärker strukturierten und entsprechend längeren Testprozess.

Updates kommen oft zu früh

Ein Trend zeichnet sich jedoch ab: Viele Unternehmen veröffentlichen Updates zu früh. Gründe dafür finden sich beispielsweise im Hype um DevOps. Obwohl die Methode ihre Vorteile hat und in immer mehr Firmen zum Einsatz kommt, bedingt sie auch erhebliche Anpassungen der Entwicklungsprozesse und vor allem der Qualitätssicherung. Beispielsweise benötigt DevOps entsprechende Testumgebungen und vor allem Testdaten, die deutlich früher im Entwicklungsprozess zur Verfügung stehen müssen. Laut dem 11ten World Quality Report fehlt bei rund 82 Prozent der Befragten in Deutschland beides.

Verfrühte und mangelhafte Updates können dann schnell zum Problem werden und betreffen nicht nur kleine Unternehmen. Auch Tech-Giganten wie Apple haben mit den Folgen zu kämpfen: Nachdem iOS 13 im Herbst 2019 ausgerollt wurde, musste das Unternehmen innerhalb kürzester Zeit mehrere Updates nachpatchen, um zum Teil kritische Sicherheitslücken zu schließen. Der Unterschied zu klassischen Unternehmen ist jedoch, dass Apple sich dieses Vorgehen leisten kann. Der Tech-Gigant verfügt über schier unendliche Entwicklerressourcen und eine breite Nutzerbasis, die Fehler schnell aufdeckt und diese ebenso schnell vergisst, sobald sie behoben sind. Damit kann Apple agile Methoden deutlich besser umsetzen beziehungsweise Fehlschläge finanziell leichter abfedern.

3 grundlegende Tipps für mehr Test-Struktur

Unternehmen, die sich ein solches Verhalten nicht leisten können, gehen in der Regel den klassischen Weg: Das Entwicklerteam führt Unit-Tests, Smoke- sowie Regressionstests durch und prüft das Release auf Systemebene. Danach macht sich das QA-Team ans Werk und prüft mit einer Mischung aus manuellen und automatisierten Tests Funktionen und neue Features. Werden keine Brüche im regulären Funktionsablauf entdeckt, wird der Release freigegeben. Doch dieses Vorgehen greift oft zu kurz, denn es richtet den Blick meist nur auf das Release selbst. Um jedoch ein wirklich mehrwertiges Update zu veröffentlichen, muss der Anspruch ein anderer sein: Das Ziel jedes Release sollte sein, ein Produkt bereit zu stellen, das in seiner Gesamtheit dem bisherigen Status quo in nichts nachsteht und dessen Qualität nachweislich gleich gut oder besser ist, als sie es bisher war. Dazu sollten mindestens folgende Maßnahmen ergriffen werden:

Implementierung von Quality Gates: Die Arbeit mit Meilensteinen sollte jedes Unternehmen in Betracht ziehen. Sie definieren die Kriterien, die es zu erfüllen gilt, bevor zur nächsten Phase eines Projektes übergegangen werden kann. Das entsprechende Quality Gate markiert den Zeitpunkt, an dem der Projektfortschritt mit den zuvor definierten Zielkriterien abgeglichen wird. Hier empfiehlt sich eine definierte Checkliste. Der Status des Gates kann dabei in drei einfache Kategorien unterteilt werden: “Pass” (die Kriterien des Quality Gates werden erfüllt), “Warn” (die Kriterien wurden nur knapp erfüllt oder der Status ist nicht restlos klar) und “Fail” (die Kriterien wurden nicht erfüllt und bedürfen einer weiteren Iteration).

Timeboxing für explorative Tests: Einige Qualitätskriterien, wie zum Beispiel Barrierefreiheit, sind deutlich aufwendiger, da sie spezielle Testingverfahren benötigen. Hierzu zählen auch explorative Tests, bei denen Testszenarien nicht vordefiniert werden, sondern die Tester Software ad hoc und mit Blick auf vermeintlich ungeplante Ereignisse prüfen. Damit diese ebenfalls wichtigen Testszenarien nicht vernachlässigt werden, ist es wichtig, regelmäßige Zeiträume zu definieren, in denen der Test absolviert wird. Eine Timebox gibt dabei nicht nur die Dauer des Tests vor, innerhalb derer der Test abgeschlossen werden muss, sondern auch die Frequenz.

Strategien zur Abarbeitung und Bug-Priorisierung: Fehler lassen sich nie vollständig vermeiden. Deshalb ist es entscheidend, einen Prozess zu definieren, der greift, sobald Fehler identifiziert werden. Dabei bietet es sich an, diesen Prozess in einen Geschäfts-unkritischen Zeitraum zu verlagern, beispielsweise in die Abendstunden und das Wochenende. Außerdem sollte bei der Priorisierung von Dringlichkeiten zur Bearbeitung darauf geachtet werden, dass sich auch der Backlog von niedrig priorisierten Bugs minimal gestaltet. Zu guter Letzt ist ein funktionierender Hotfix-Prozess wichtig, in dem kritische Fehler zeitnah bearbeitet werden können.

Qualitätsstandards als fixer Leuchtturm

Am Ende liegt es oft bei einzelnen Personen, die darüber entscheiden, ob ein Release veröffentlicht wird und wann. Und diese Person sollte sich nicht auf ihr Bauchgefühl verlassen müssen. Stattdessen gibt es heute Qualitäts-Scores, wie den von Applause, die Daten-basierte Entscheidungsgrundlagen bieten. Die für Qualitätssicherung zuständige Person im Unternehmen erhält dadurch Einblicke in verschiedene Metriken, Informationen zu kritischen Points of Failure und ein Protokoll, das fundierte Entscheidungen ermöglicht und Unsicherheit im Softwareentwicklungsprozess reduziert.

Autor
Erfahren Sie mehr 
Jan Wolter ist General Manager EU bei Applause. Als General Manager leitet er für Applause den europäischen Geschäftsbereich und ist verantwortlich für den Ausbau des Unternehmens im europäischen Markt. Seine Hauptaufgabe besteht darin, sicherzustellen, dass die Ziele von Applause Europe in Bezug auf das Umsatzwachstum und die Kundenakquisition umgesetzt werden. Außerdem sorgt er dafür, dass die Qualität und die Kundenzufriedenheit des Unternehmens auf höchstem Niveau bleiben. Bevor er zu Applause kam, war Jan CEO und Mitbegründer von testhub, dem deutschen Softwaretesting-Anbieter, das sich im Mai 2014 mit Applause zusammenschloss.
Erfahren Sie mehr