Keine Angst vor dem Scheitern!

Lehren aus der alten Welt

Als ich meine Karriere in der IT als Softwaretester begann, war das erste Mantra, das mir eingebläut wurde, "je früher man ein Problem findet, desto billiger ist es zu beheben". Lange Zeit waren dies und das Mantra "Qualität ist kostenlos" die Grundlage und Rechtfertigung für die Welt der Qualitätssicherung.

In den letzten 20 Jahren hat sich die Welt der Softwareentwicklung mit Agile, DevOps, CI/CD, Cloud usw. jedoch drastisch verändert. All diese Ansätze und Techniken haben die Geschwindigkeit der Bereitstellung und die Qualität des Produkts radikal erhöht.

Das wirft die Frage auf: Ist es immer noch der beste Ansatz für Softwarequalität, alles so früh wie möglich zu testen, oder gibt es heutzutage alternative Ansätze?

Winde der Veränderung

Die meisten von uns werden mit der jahrzehntealten Böhm-Kurve (siehe Abbildung 1) vertraut sein, die besagt, dass Fehlerbehebungen in der Produktion um ein Vielfaches teurer sind als Fehlerbehebungen während der Entwicklung. Dieses Bild wird verwendet, um eine fast schon hektische Konzentration auf möglichst viele und möglichst frühe Tests zu rechtfertigen. Auch heute noch wird es häufig verwendet, um strategische Qualitätsentscheidungen zu treffen. Aber ist das in der modernen Landschaft der Softwareentwicklung noch sinnvoll?

Um diese Frage zu beantworten, lassen Sie uns zunächst einen Blick auf die Art und Weise werfen, wie wir heutzutage Software entwickeln und wie sich dies auf die Böhmsche Kurve auswirkt (siehe Abbildung 2):

• Agile brachte uns besser abgestimmte Anforderungen (was zu weniger Fehlern führte) und eine effektivere Softwareentwicklung (was zu weniger Fehlern führte). Dadurch wurde die Spitze der "eingeführten Probleme" in der Entwicklungsphase reduziert.
• Die kontinuierliche Integration automatisierte den Prozess der Zusammenführung von Code und das Testen des Ergebnisses. Dadurch konnten Fehler früher und schneller identifiziert werden.
• DevOps gab den Teams Autonomie und Unabhängigkeit bei der Bereitstellung, was u.a. zu einem weniger schwerfälligen und daher kostengünstigeren Bereitstellungsprozess führte.
• Continuous Delivery stellte den Teams Bereitstellungsfunktionen zur Verfügung, wodurch die Bereitstellung schneller und konsistenter wurde.

Wenn wir die Auswirkungen der modernen Softwareentwicklung über die klassische Abbildung legen, erhalten wir ein Diagramm, das eine ganz andere Geschichte erzählt (siehe Abbildung 3). Mit einem höheren Qualitätsniveau, einem höheren Automatisierungsgrad und kürzeren Bereitstellungszyklen sind die Kosten für Fehlerbehebungen in der Produktion wahrscheinlich immer noch höher als die Kosten für Fehlerbehebungen in der Entwicklung, aber der Unterschied liegt nicht mehr in einer Größenordnung.

Eine neue Strategie auf der Grundlage alter Konzepte

Moderne Softwareentwicklungsansätze stellen die Aussage "frühes Reparieren ist immer besser" eindeutig in Frage. Wie wirkt sich das auf unsere Einstellung zur Qualität aus?

Heutzutage können Entwicklungsteams schneller, billiger und einfacher in die Produktion einführen, als dies vor 10 Jahren in einer Testumgebung möglich war. Mit all dieser erhöhten Geschwindigkeit und Flexibilität sind wir an einem Punkt angelangt, an dem es so etwas wie "zu viel Qualität" geben kann. Im ursprünglichen LEAN-Modell wurde dies als "zusätzliche Verarbeitung" bezeichnet, und heute würden wir es "gold-plated engineering" nennen.

Die Behebung von Fehlern, wenn sie in der Produktion zu einem Problem werden, sollte daher eine realistische Option in Ihrer Qualitätssicherungsstrategie sein. Die Wahrscheinlichkeit und die Auswirkungen eines Teils Ihrer Anwendung, der nicht wie vorgesehen funktioniert, sollten bei dieser Entscheidung eine Rolle spielen. Letztendlich ist die Zeit begrenzt, so dass Sie sich entscheiden sollten, ob Sie sie für mehr Qualität oder mehr Funktionalität ausgeben.

Natürlich kostet es immer noch mehr Zeit, Dinge zu spät zu reparieren, als sie zu verhindern, aber wenn Sie fast sofort in die Produktion gehen können, können Sie anfangen, anders über Zwischenfälle zu denken.

Beginnen Sie mit der Messung von Fehlern

Letztendlich wollen Sie so nah wie möglich an der Qualität sein, die Ihre Kunden von Ihnen erwarten; alles, was darüber hinausgeht, ist faktisch eine Extrabearbeitung. Dieser Ansatz ist auch die Grundlage des SRE-Ansatzes von Google. Kundenwünsche (SLA) werden in messbare Indikatoren (SLI) umgewandelt und Schwellenwerte (SLO) definieren das Verhalten der Entwicklungsteams. Solange die Teams unter dem Schwellenwert bleiben, können sie Zeit für neue Funktionen aufwenden. Wenn das Serviceziel jedoch in Gefahr gerät, muss die Entwicklung ihre Zeit darauf verwenden, Probleme zu beheben und wieder in die "sichere Zone" zu gelangen.

Das Konzept des Schwellenwerts kann dazu verwendet werden, die optimale Qualitätsstrategie zu gestalten. Eine Umsetzung könnte darin bestehen, ein Diagramm für den Abbau des Qualitätsbudgets zu führen (siehe Abbildung 4). Die Teams geben an, wie viel Zeit sie für Zwischenfälle, Wartung und Qualitätsverbesserungen aufwenden möchten, und beginnen, die tatsächlich aufgewendete Zeit zu verfolgen. Nach einer Weile wird deutlich, ob sie sich in der Zone "zu viel Sicherheit" oder "zu wenig Zuverlässigkeit" befinden.

Dieser Ansatz erfordert einen Paradigmenwechsel. Es reicht nicht mehr aus, nur zu wissen, was schief gehen kann oder was kaputt ist. Es wird wichtiger zu verstehen, wie man sich verhalten muss, wenn etwas schief geht. Aber das ist ja auch ein Aspekt der Qualität. Bei der Qualität geht es nicht nur um Vorbeugung, sondern auch darum, sich darauf einzustellen, dass ständig etwas kaputt geht, dies zu akzeptieren und zu trainieren, wie man auf Zwischenfälle reagiert.

Nehmen Sie Zwischenfälle an!

Der Hype um den Linksruck in der Softwareentwicklung hat zu einer Denkweise geführt, bei der es darum geht, ständig alle Probleme zu vermeiden, ohne an das erforderliche Qualitätsniveau zu denken. Es ist an der Zeit, das Drehbuch umzudrehen und das Gleichgewicht wiederherzustellen. Unternehmen sollten damit beginnen, die erforderliche Qualität zu spezifizieren und ihre Qualitätsstrategien entsprechend auszurichten. Mit der Geschwindigkeit, die die moderne Softwareentwicklung bieten kann, sind Produktionsausfälle nicht mehr immer eine schlechte Sache. Die Akzeptanz von Zwischenfällen als Teil Ihrer Strategie für Abweichungen könnte eine effektivere Nutzung Ihrer wertvollen Zeit sein.