Immer wieder scheitern IT-Vorhaben an der Sprengung von Zeit- und Kostenrahmen. Wenn Vorhaben trotz dieser beiden Probleme durchgeführt werden, leiden sie während ihres Verlaufs an „Krankheiten“ und verursachen zusätzliche Kosten in Produktion und Wartung. Eine Lösung soll Software-Qualitätssicherung (QS) bieten. Dabei gilt es jedoch, die genaue Dosierung von QS in der eigenen IT im Auge zu behalten.
Spezifikationsmängel
Oft sind die Anforderungsspezifikation eines IT-Systems sowie das nachfolgende Fach- und IT-Konzept lückenhaft dokumentiert und konkretisiert. Dies führt dazu, dass die Auftraggeber parallel zur Implementierung ständig „neue“ Anforderungen einreichen, deren Tragweite sich erst Schritt für Schritt offenbart. Eine solche „Entwicklung auf Zuruf“ verursacht einen hohen Aufwand an Nacharbeiten. Es entstehen Verzögerungen. Abhängigkeiten zu parallel laufenden Entwicklungen müssen ständig korrigiert und nachbearbeitet werden, und auch Motivationsverlusten bei den beteiligten Team-Mitgliedern stellen sich ein. Solche Spezifikationsmängel sind nicht zu verwechseln mit einem echten Anforderungsmangel, bei dem parallel zur Entwicklung neue Business-Anforderungen entstehen, die beim Systemdesign noch nicht existierten. Oft ist Spezifikationsmangel durchaus hausgemacht und kann durch geeignete Maßnahmen minimiert werden.
Übergabemängel
Hat ein Entwicklungsprojekt keine klar definierten „Quality Gates“ zwischen den unterschiedlichen Projektstufen gesetzt, sind Übergabe und Abnahme der jeweiligen Systemkomponenten zwangsläufig mangelhaft. Dies ist der Fall, wenn die Entwickler-tests durch die Implementierer die Systemfunktionen nicht vollständig abdecken. Die Erfahrung zeigt, dass insbesondere Funktions- und Integrationstests oft nur sehr oberflächlich erfolgen. Die Folge ist ein hohes Fehleraufkommen im Systemintegrations- und Abnahmetest und damit hohe Kosten. Denn je später ein Fehler entdeckt wird, umso mehr Aufwand verursacht er durch Nachbesserungsarbeiten oder Vertrauensverlust auf Seiten des Fachbereichs. Wenn ein Fehler in der Anforderungsphase behoben wird und dies zum Beispiel 1.000 Euro kostet, verursacht der gleiche nicht entdeckte Fehler schon 12.000 Euro, wenn er erst während der Implementierung beseitigt wird. Sollte er sich sogar in den Betrieb hinein schmuggeln, steigt der Reparaturaufwand auf 90.000 Euro.
Produktionsmängel
Viele Abnahmetests prüfen insbesondere unter Zeitdruck nur wenig mehr als die kritischen Geschäftsanforderungen. Außerdem können Abnahmetests unter dem Druck der gesetzten Einführungstermine oft nicht beliebig ausgeweitet werden. Die dadurch auftretende mangelnde Qualität während der Abnahme führt wiederum zu Produktionsmängeln. Sie sind oft die folgenreichsten und teuersten Krankheitssymptome von IT-Systemen: Denn unter ihnen haben oft auch die Kunden zu leiden. Zu den hohen Nachbesserungskosten kommen dann auch noch Imageverluste.
Diesen Mangelerscheinungen lässt sich schon mit wenigen einfachen Maßnahmen vorbeugen. Erstens: Unternehmen sollten sicher stellen, dass mindestens 25 Prozent ihrer Aufwände in Software-Testen und -Qualitätssicherung fließen. Mit weniger kommt kein IT-Projekt aus. Zweitens: Projekte benötigen Durchblick und Transparenz. Sie müssen Tests und den Status der Bearbeitung deshalb fortlaufend und systematisch dokumentieren. Und drittens: Die Ergebnisse müssen kontinuierlich ausgewertet werden, denn sie enthalten wichtige Informationen über die Gesundheitslage eines Projektes.
Projekttransparenz ist wichtig, da die Projekte so immer wissen, wie viele Fehler sie gefunden und welchen Folgeaufwand sie dadurch vermieden haben.
Überdosis Qualität?
Umgekehrt stellt sich die Frage, ob es auch eine Überdosis an Qualität gibt, bei der nicht notwendige Investitionen in die Qualitätssicherung fließen? Dies ist sogar häufiger der Fall – allerdings nicht in dem Sinn, dass Unternehmen oder Projekte generell zu viel in QS investieren. Vielmehr fließen die Ressourcen oft an die falschen Stellen. Oft werden für das Geschäft weniger wichtige Systemfunktionen intensiv geprüft, während funktionskritische Komponenten unter den Tisch fallen. Ein entscheidender Erfolgsfaktor ist deshalb auch das frühzeitige Setzen von Testprioritäten und die laufende Beobachtung der Prozesse. Sie vermeiden solche Aufwände und verhindern insofern ein Zuviel an nicht effektiver Qualität.
Standard ist heute ein risikobasierter Ansatz in der QS: Unabhängig vom verfügbaren Budget sollten sich die Verantwortlichen am Anfang von Projekten klar darüber werden, welches Risiko sie eingehen, wenn sie bestimmte Maßnahmen nicht durchführen. Selbst wenn die Entscheider beschließen, ein bestimmtes Risiko nicht zu neutralisieren, haben sie dieses Urteil zumindest bewusst getroffen und können mit dem eingegangenen Risiko bewusst planen.
Ebenso benötigt die Erfolgskontrolle der beschlossenen QS-Maßnahmen Systematik. Wenn die IT-Verantwortlichen wissen wollen, ob die Investitionen in QS ihr Ziel erreicht haben oder gar über das Ziel hinaus geschossen sind, helfen fortlaufend erhobene Metriken. Nur wer quantitativ belegen kann, welchen Nutzen seine QS-Maßnahmen bringen, kann gezielt umsteuern, wenn die Werte über oder unter Soll liegen sollten. Hinzu kommt: Nur wer auf diese Weise nachweisen kann, wie viele und welche Fehler er gefunden hat, kann auch beziffern, welche Folgekosten er vermieden hat. Und nur mit diesen Zahlen wiederum, hat ein IT-Vertreter einen guten Stand, wenn er beim Unternehmensmanagement Mittel für die Qualitätssicherung einfordert.
Langfristig und nachhaltig
Soll die Software-Qualitätssicherung langfristig erfolgreich sein, gilt es die individuellen Besonderheiten von Unternehmen und Projekten zu berücksichtigen. Dazu zählen zum Beispiel die eingesetzten Technologien, Entwicklungsverfahren, die Architektur und Komplexität der Systeme, das Know-how der Mitarbeiter oder die Qualität der Anforderungen. Wer diese Aspekte ausreichend berücksichtigen will, sorgt vor allem für eine Abstimmung der allgemeinen Entwicklungsplanung einerseits mit dem Vorgehen der Qualitätssicherung und der Testplanung andererseits. Im Mittelpunkt steht die Frage: Wann sind welche Funktionen, Teilsysteme und am Ende das Gesamtsystem fertig für die einzelnen Teststufen? Je früher integrierte oder integrierbare Komponenten vorliegen, umso eher können auch die Tests beginnen.
Das frühzeitige Testen von Komponenten ist deshalb wichtig, da die meisten Probleme in den Anforderungen, Fachkonzepten oder Design-Entscheidungen begründet liegen. Derartige Probleme können genereller Natur sein, können sich also übergreifend auf unterschiedlichste Entwicklungsaktivitäten und -phasen auswirken. Je früher solche Fehler erkannt und behoben werden, umso kleiner ist der mit ihnen verbundene Korrekturaufwand. Dies verringert die Gefahr von Terminverschiebungen nicht nur zum Ende eines Projekts hin, sondern vielfach auch schon mitten im laufenden Projekt. So steigt nicht nur die Qualität der Systeme. Zugleich sinkt auch der Entwicklungs- und Testaufwand im Hinblick auf Zeit und Kosten.
Zur Bündelung und Steuerung all dieser Maßnahmen bietet sich der Aufbau einer zentralisierten Instanz für Qualitätssicherung und Testmanagement an. Zumal diese Aufgaben mittlerweile im Zentrum eines neuen Berufsbildes in der IT stehen. Wie auch das Software-Engineering fokussieren die entsprechenden Schulungen und Ausbildungen auf eigene Prozesse, Methoden, Verfahren und Best Practices für den Test. Sie stellen sicher, dass Qualitätssicherer eine professionelle, effektive und effiziente Arbeit leisten.
