Wir beginnen mit einem bewusst provokanten Satz:
Qualität kann nicht in Software oder IT-Systeme „hineingetestet“ werden.
Was bedeutet das?
Qualität entsteht nicht erst am Ende eines Projekts durch Testaktivitäten. Sie muss von Anfang an systematisch aufgebaut werden. Für die Entwicklung eines Systems ist deshalb ein strukturiertes Qualitätssicherungskonzept erforderlich.
Dieses betrifft nicht nur die Testfälle, sondern ebenso Architektur, Komponenten, Entwicklungsprozesse, Auslieferungen, Patchabläufe und das Fehlermanagement. Qualitätssicherung begleitet die Entwicklung also von Beginn an parallel zu den eigentlichen Fach- und Umsetzungskonzepten.
In vielen IT-Projekten wird Qualitätssicherung noch immer zu spät betrachtet. Dann werden Probleme erst sichtbar, wenn Termine knapp, Budgets belastet und Produktivsetzungen bereits vorbereitet sind.
Ein wirksames QS-Konzept reduziert genau dieses Risiko. Es schafft klare Regeln für Entwicklung, Test, Übergaben und Nachvollziehbarkeit. Dadurch werden Fehler nicht nur entdeckt, sondern bereits in ihrer Entstehung begrenzt.
Im Folgenden beschränke ich mich auf drei Punkte, die in der Praxis besonders häufig über die Stabilität eines Systems entscheiden.
Professionelle Softwareentwicklung benötigt klar getrennte Entwicklungsstufen, beispielsweise Entwicklungsumgebung, Testumgebung, Auslieferungsumgebung und – soweit vorhanden – eine Kundentestumgebung.
Üblicherweise wird dabei mit einem Code-Management-System gearbeitet. Auslieferungen sollten automatisiert per Skript erfolgen und nachvollziehbar dokumentiert sein.
Kritisch wird es, wenn aus Zeitgründen ein Patch direkt auf der Kundenanlage eingespielt wird. In diesem Fall muss die Änderung zwingend auf die vorgelagerten Entwicklungs- und Teststufen „nachgezogen“ werden. Nur dann ist sichergestellt, dass die Korrektur bei der nächsten regulären Auslieferung weiterhin enthalten ist.
Fehlt dieser konsequente Prozess, treten typische Fehlerbilder auf:
- bereits behobene Fehler erscheinen in späteren Versionen erneut,
- Sonderpatches werden versehentlich überschrieben,
- Seiteneffekte neuer Entwicklungen erzeugen zusätzliche Probleme.
In vielen Projekten ist dies keine technische Nebensächlichkeit, sondern eine der Hauptursachen für wiederkehrende Instabilität.
Ein Entwickler erkennt beim Eigentest im Durchschnitt nur einen Teil seiner eigenen Fehler. Häufig wird als grobe Faustregel angenommen, dass beim reinen Eigentest maximal etwa 80 % der Fehler gefunden werden.
Der Grund ist nachvollziehbar: Wer eine Lösung selbst entworfen und umgesetzt hat, prüft sie meist entlang der eigenen Annahmen und Denkwege. Genau deshalb bleibt ein Teil der Risiken unentdeckt.
Ein unabhängiger Fremdtest ist daher unverzichtbar. Er ergänzt den Eigentest um:
- einen anderen Blick auf die Anwendung,
- realistische Nutzungs- und Fehlerszenarien,
- eine systematischere Prüfung von Grenzfällen und Seiteneffekten.
Gerade bei geschäftskritischen Systemen darf Qualitätssicherung deshalb nicht auf den guten Willen der Entwickler allein reduziert werden.
Moderne Anwendungen bestehen nicht nur aus selbst entwickeltem Code. Sie beruhen auf einer Vielzahl von Plattformbestandteilen, Bibliotheken, Frameworks und Drittkomponenten.
Genau hier entstehen in der Praxis regelmäßig Risiken. Sicherheitslücken in Plattformkomponenten müssen geschlossen werden, Bibliotheken werden aktualisiert, Frameworks ändern ihr Verhalten.
Die typische Situation ist bekannt: Eine Bibliothek wird aus guten Gründen auf eine neue Version gehoben – etwa wegen einer Sicherheitslücke. Danach zeigt sich, dass Teile der Anwendung anders reagieren oder gar nicht mehr funktionieren.
Ursachen können unter anderem sein:
- strengere Typ- und Variablendefinitionen,
- verändertes Verhalten vorhandener Funktionen,
- neue oder geänderte Abhängigkeiten zu anderen Komponenten.
Die Folge ist häufig, dass große Teile des Systems erneut getestet werden müssen – obwohl am eigenen Anwendungscode nur wenig oder gar nichts geändert wurde.
Genau deshalb gehören Bibliotheks- und Plattformänderungen in eine ernsthafte Qualitätssicherungsstrategie.
Selbstverständlich verursacht Qualitätssicherung Aufwand und Kosten. Diese Sicht ist richtig – aber unvollständig.
Denn mangelnde Qualität verursacht in der Regel deutlich höhere Folgekosten:
- Projektverzögerungen,
- erhöhter Fehlerbehebungsaufwand,
- unsichere Produktivsetzungen,
- Vertrauensverlust beim Auftraggeber und bei den Anwendern.
Qualitätssicherung ist deshalb kein Luxus und kein lästiger Anhang der Entwicklung, sondern ein wirtschaftlich sinnvoller Bestandteil professioneller Projektsteuerung.
Qualität entsteht nicht am Ende eines Projekts, sondern durch ein strukturiertes Vorgehen von Anfang an.
Wer Auslieferungsprozesse sauber organisiert, unabhängige Tests verankert und die Risiken von Plattformen und Bibliotheken ernst nimmt, reduziert Fehlerkosten, erhöht die Stabilität und verbessert die Lieferfähigkeit eines IT-Projekts deutlich.
Prüfen Sie daher Ihre Projektorganisation und Ihre Budgets genau unter diesem Blickwinkel – und verankern Sie Qualitätssicherung als konstruktiven, verbindlichen Bestandteil des gesamten Projekts.