Die Diskussion über Softwarequalität beginnt fast immer mit Werkzeugen. Sie sollte mit den Konsequenzen beginnen. Es gibt eine Version der Diskussion über Softwarequalität, die die meisten Entwicklungsteams schon oft geführt haben. Sie läuft ungefähr so: Die Testabdeckung ist zu gering, der QA-Prozess ist zu langsam, die Werkzeuge sind nicht gut genug integriert und es muss sich etwas vor der nächsten Veröffentlichung ändern.
Dieses Gespräch ist nützlich, soweit es geht. Aber es neigt dazu, auf der Symptomebene zu bleiben, bei den sichtbaren Reibungen und den unmittelbaren Engpässen, ohne zur zugrunde liegenden Frage vorzudringen, die tatsächlich bestimmt, ob ein Team sich verbessert: Was kostet schlechte Qualität eigentlich und messen wir diese Kosten richtig? Aufbau Qualigentic drängte uns, dies sorgfältiger als zuvor zu durchdenken. Hier ist, was wir herausgefunden haben.
Die sichtbaren Kosten sind nicht die teuren
Wenn Organisationen versuchen, die Kosten von Softwarequalitätsproblemen zu berechnen, beginnen sie typischerweise mit dem, was sie messen können: der Anzahl der gemeldeten Fehler, der für Nacharbeiten aufgewendeten Zeit, den Support-Anfragen, die auf einen Fehler in der Produktion zurückzuführen sind. Diese Zahlen sind real und wichtig. Aber sie unterschätzen systematisch die tatsächlichen Kosten mangelnder Qualität, weil sie die Kosten übersehen, die kein Ticket generieren. Der Ingenieur, der zwei Stunden mit der Fehlersuche verbringt, die eine bessere Testsuite in zwei Minuten hätte erkennen können – diese Zeit erscheint nicht als Qualitätskosten. Sie erscheint als normale Entwicklungszeit. Die Produktentscheidung, die verschoben wird, weil das Team nicht genügend Vertrauen in die bestehende Codebasis hat, um sicher eine neue Funktion hinzuzufügen – auch das erscheint nicht als Qualitätskosten. Es erscheint als langsamere Entwicklungsgeschwindigkeit. Der Kunde, der nicht verlängert, oder die Kaufentscheidung zugunsten eines Wettbewerbers, weil die Software innerhalb von sechs Monaten drei Ausfälle hatte – das mag sich im Umsatz niederschlagen, wird aber selten auf den Entwicklungsprozess zurückgeführt, der diese Ausfälle ermöglicht hat.
Wenn man die unsichtbaren Kosten zu den sichtbaren hinzurechnet, ändert sich das Bild erheblich. Qualitätsprobleme sind fast immer teurer, als sie scheinen, und die Lücke zwischen den scheinbaren und den tatsächlichen Kosten wächst tendenziell mit der Komplexität und Kritikalität der Software.
Warum der Standardansatz zur Qualität das Problem nicht löst
Die Standardreaktion auf Probleme mit der Softwarequalität folgt einem vorhersehbaren Muster: Investition in bessere Testwerkzeuge, Erhöhung der Testabdeckungsziele, Hinzufügen einer QS-Phase zum Entwicklungsprozess und Erfassung der Anzahl von Fehlern, die vor der Veröffentlichung gefunden wurden. Dies sind sinnvolle Maßnahmen. Sie verbessern zwar die Ergebnisse. Sie behandeln die Qualität jedoch als nachgelagerte Aktivität, etwas, das nach dem Schreiben des Codes geschieht, um zu überprüfen, ob das Gebaute korrekt ist.
Das grundlegende Problem dieses Modells ist, dass es Qualität als Funktion der Verifizierung und nicht als Funktion des Designs betrachtet. Und wenn Qualität hauptsächlich eine Verifizierungsaktivität ist, steht sie immer im Widerspruch zur Liefergeschwindigkeit, da Verifizierung Zeit kostet, Zeit knapp ist und Knappheit zu Abkürzungen führt. Die Teams, die durchweg zuverlässige Software produzieren, haben eine andere Wahl getroffen. Sie betrachten Qualität als Designaktivität – etwas, das geschieht, während das System konzipiert und aufgebaut wird, nicht danach.
Die Fragen lauten nun anders: Nicht “Funktioniert das?”, sondern “Unter welchen Bedingungen versagt das, und haben wir bei der Entwicklung Vorkehrungen gegen diese Bedingungen getroffen?” Diese Verlagerung verändert die Ökonomie der Qualität.
Wenn Ausfallmodi während der Entwicklung berücksichtigt werden, sind die Kosten für deren Behebung gering. Wenn sie in der Produktion entdeckt werden, sind die Kosten hoch. Der Unterschied liegt nicht in der Komplexität der Behebung, sondern in der Phase, in der sie auftritt.
Das Wartungsproblem, das niemand im Budget einplant
Es gibt einen bestimmten Kostenfaktor, dem mehr Aufmerksamkeit geschenkt werden sollte, als ihm normalerweise zuteilwird: die Kosten für die Aufrechterhaltung der Funktionsfähigkeit einer bestehenden Testsuite.
Die meisten Teams konzentrieren sich, wenn sie über die für Qualität erforderlichen Investitionen nachdenken, auf die Kosten für das Erstellen von Tests. Das ist der sichtbare, budgetierbare Teil der Arbeit. Schwieriger zu beziffern sind die laufenden Kosten für die Pflege dieser Tests im Zuge der Weiterentwicklung der Codebasis: das Aktualisieren von Skripten nach Codeänderungen, das Entfernen redundanter Tests, die mittlerweile nichts mehr prüfen, sowie die Diagnose, ob ein Fehler auf einen echten Defekt oder auf einen veralteten Test zurückzuführen ist, der die Funktionsweise des Systems nicht mehr widerspiegelt.
Branchenangaben zufolge liegt der Anteil des QA-Aufwands, der für die Wartung aufgewendet wird, durchweg zwischen 60 und 70 Prozent. Das ist ein erheblicher Teil der Entwicklungszeit, der nicht dafür verwendet wird, neue Probleme zu finden, sondern dafür, die bestehende Infrastruktur zur Fehlererkennung funktionsfähig zu halten.
Diese Wartungsbelastung verschärft sich in regulierten Branchen. In Umgebungen, die bestimmten DORA, Solvenz II oder PSD2, Qualität ist nicht nur eine interne Angelegenheit der Entwicklung, sondern auch ein Thema bei Audits. Die Aufsichtsbehörden verlangen Nachweisketten, keine Screenshots. Sie wollen einen nachvollziehbaren Pfad von der Anforderung über die Testdurchführung bis hin zum archivierten Ergebnis sehen und diese Nachweise bei Bedarf abrufen können. Der manuelle Aufbau und die Pflege dieser Nachweiskette stellen für eine ohnehin schon überlastete Qualitätssicherungsabteilung einen erheblichen und oft unterschätzten Kostenaufwand dar.
Das ist eines der Probleme Qualigentic wurde entwickelt, um genau dieses Problem anzugehen. Die Funktion zur autonomen Wartung, die veraltete, fehlerhafte und redundante Tests erkennt und diese automatisch überarbeitet, existiert genau deshalb, weil wir erkannt haben, wie viel technische Kapazität durch diese Arbeit gebunden wurde. Und die vollständige Rückverfolgbarkeit der Prüfkette – von der Anforderung bis zum archivierten Ausführungsergebnis – existiert, weil wir erkannt haben, dass in regulierten Branchen die Nachweiskette keine optionale Infrastruktur ist. Sie ist eine Anforderung, die mit Kosten verbunden ist, und diese Kosten sollten eingeplant und nicht einfach absorbiert werden.
Was Qualigentic uns zur Konfrontation abverlangte
Qualigentic ist ein System, das zuverlässig sein muss. Aufgrund der Art seiner Funktionsweise bleiben Qualitätsprobleme nicht auf sich beschränkt, sondern breiten sich aus, verstärken sich und haben Konsequenzen, die über den unmittelbaren technischen Ausfall hinausgehen. Bei der Entwicklung mussten wir den Zusammenhang zwischen Qualität und Architektur deutlicher herausarbeiten, als wir es gewohnt sind. Die bereits früh im Entwurfsprozess getroffenen Entscheidungen darüber, wie Komponenten miteinander interagieren, wo Validierungen stattfinden und wie Fehler aufgedeckt und behandelt werden, haben Konsequenzen, die sich über Monate und Jahre hinweg auswirken – nicht nur im aktuellen Sprint.
Drei Dinge fielen aus diesem Prozess besonders auf, die unserer Meinung nach breitere Anwendbarkeit haben.
Dieses Modell funktioniert, wenn die Rückkopplungsschleife schnell ist und das QA-Team über genügend Kontext verfügt, um das Wesentliche zu erkennen. In der Praxis führt es jedoch meist zu einem Engpass und einer Unternehmenskultur, in der Qualität als Aufgabe anderer angesehen wird, bis es zu einer Krisensituation kommt. Wenn die Verantwortung für die Qualität verteilt ist und jeder Entwickler ein echtes Verantwortungsbewusstsein für die Zuverlässigkeit seiner ausgelieferten Produkte empfindet, ändert sich die Dynamik. Probleme werden früher angesprochen, Kompromisse werden bewusster eingegangen, und die kumulierten Kosten kleiner Qualitätseinbußen steigen nicht unbemerkt an, bis sie zu einer Krise führen.
Dieses Modell funktioniert, wenn die Rückkopplungsschleife schnell ist und das QA-Team über genügend Kontext verfügt, um das Wesentliche zu erkennen. In der Praxis führt es jedoch meist zu einem Engpass und einer Unternehmenskultur, in der Qualität als Aufgabe anderer angesehen wird, bis es zu einer Krisensituation kommt. Wenn die Verantwortung für die Qualität verteilt ist und jeder Entwickler ein echtes Verantwortungsbewusstsein für die Zuverlässigkeit seiner ausgelieferten Produkte empfindet, ändert sich die Dynamik. Probleme werden früher angesprochen, Kompromisse werden bewusster eingegangen, und die kumulierten Kosten kleiner Qualitätseinbußen steigen nicht unbemerkt an, bis sie zu einer Krise führen.
Die Messfrage
Wenn schlechte Qualität teurer ist, als es den Anschein hat, bedeutet dies, dass auch die Investitionen, die zu ihrer Behebung erforderlich sind, höher ausfallen, als Unternehmen in der Regel einplanen. Daraus ergibt sich ein praktisches Problem: Wie lässt sich diese Investition gegenüber denjenigen begründen, die sich ausschließlich an den sichtbaren Kostenzahlen orientieren? Die Antwort lautet: Man muss ändern, was man misst. Die Kennzahlen, die die meisten Entwicklungsteams erfassen: Testabdeckung, Fehleranzahl und durchschnittliche Zeit bis zur Fehlerbehebung sind nachlaufende Kennzahlen. Sie geben Aufschluss darüber, was passiert ist, nicht aber darüber, was es gekostet hat oder was als Nächstes passieren wird. Nützlicher sind Kennzahlen, die die unsichtbaren Kosten erfassen: den Anteil der Entwicklungszeit, der reaktiv statt produktiv ist, die Häufigkeit, mit der die Entwicklung neuer Funktionen durch Bedenken hinsichtlich der Stabilität des bestehenden Systems verlangsamt wird, sowie die Korrelation zwischen Qualitätskennzahlen und der Liefergeschwindigkeit im Zeitverlauf. Diese Zahlen sind schwieriger zu ermitteln. Aber sie vermitteln ein genaueres Bild von den tatsächlichen wirtschaftlichen Aspekten der Qualität und machen die Diskussion über Investitionen wesentlich handhabbarer.
| Was Sie messen | Was die meisten Teams verfolgen | Was wirklich zählt |
|---|---|---|
| Testabdeckung | % der abgedeckten Leitungen | ✓ Ausfallmodi abgedeckt |
| Fehleranzahl | Tickets protokolliert | ✓ Fehler, die nie ein Ticket erreicht haben |
| QA-Investition | Werkzeuge und Personal | Wartungsaufwand + unsichtbare Kosten |
| Liefergeschwindigkeit | Story Points pro Sprint | ✓ Geschwindigkeit verloren durch Qualitätsangst |
| Vorfallkosten | Zeit für die Lösung | ✓ Umsatz und Vertrauen wirken sich nachgelagert aus |
| Qualitätsverantwortung | Verantwortlichkeit des QA-Teams | ✓ Jeder Ingenieur, jeder Sprint |
Was das in der Praxis bedeutet
Die praktische Auswirkung, Qualität auf diese Weise zu betrachten, ist, dass sich die lohnenden Interventionen von denen unterscheiden, die tendenziell Priorität haben. Die Werkzeuge sind wichtig, aber sie sind weniger wichtig als das Prozessdesign. Ein Team mit durchschnittlichen Werkzeugen und einem gut gestalteten Qualitätsprozess wird ein Team mit ausgezeichneten Werkzeugen und einem schlecht gestalteten Prozess durchweg übertreffen.
Prozessdesign ist wichtig, aber weniger wichtig als wenn Qualitätsdenken in den Entwicklungszyklus einfließt. Teams, die Qualität während des Designs berücksichtigen, werden Teams, die Qualität während der Verifizierung berücksichtigen, durchweg übertreffen, unabhängig davon, wie gut der Verifizierungsprozess ist. Und letztendlich sind beide nachrangig gegenüber der Kultur, ob die Leute, die die Software entwickeln, ehrliche Verantwortung für deren Zuverlässigkeit übernehmen und ob die sie umgebende Organisation diese Verantwortung belohnt oder heimlich zugunsten der Liefergeschwindigkeit bestraft. Qualität ist ein technisches Problem in dem Sinne, dass sie technisches Können erfordert, um sie zu lösen. Aber die Entscheidungen, die darüber entscheiden, ob ein Team zuverlässige Software produziert, sind größtenteils keine technischen Entscheidungen. Es sind organisatorische Entscheidungen, Prozessentscheidungen und Kultur entscheidungen, die vor dem Code getroffen werden und deren Folgen lange nach der Veröffentlichung auftreten.
Bei Zauberkasten, Qualität sehen wir nicht als Phase im Entwicklungsprozess, sondern als Arbeitsweise. Qualigentic drängte uns, diesbezüglich strenger zu sein. Die Lehren aus diesem Prozess fließen in jeden Projektansatz ein, den wir verfolgen.
Regulatorfreundliche Nachweise in 6–8 Wochen.
