Anforderungsbasiertes Testen

Hilde klappte die Zeitschrift zu und schaute ihn durchdringend an. Theo fühlte sich einen Moment lang unwohl, aber das war nur ein kurzer Augenblick der Unsicherheit. Er kannte den Aufsatz aus der neuesten Ausgabe von „Softwarekatastrophen" schon, aus dem Hilde gerade zitiert hatte. Insbesondere die Grafik, auf der eindrucksvoll dargestellt wurde, wie teuer die Behebung eines Fehlers war, je weiter der Softwareentwicklungsprozess fortgeschritten war. Das unterstützte lediglich das Credo aller Tester und Testmanager, so früh wie möglich mit qualitätssichernden Maßnahmen anzufangen. Er ließ die letzten Monate Revue passieren.

Dabei scrollte er durch die lange Liste von Anforderungen, so wie er das seit Projektbeginn immer wieder vor jedem Planungsmeeting getan hatte. Das sah alles sehr gut aus: Anforderungen waren eindeutig und widerspruchsfrei beschrieben und jeweils durch Akzeptanzkriterien begleitet, die durch das Testteam verifiziert werden konnten. Dabei war das eindeutige Vergeben einer ID unerlässlich gewesen und diese ID zog sich durch alle Artefakte des Softwareentwicklungszyklus.

Zu Projektbeginn hatten sie sich vorgenommen, zu jedem Akzeptanzkriterium mindestens einen Testfall zu schreiben. In der Praxis waren es dann natürlich viel mehr geworden. Aber diese systematische, strukturierte Vorbereitung erleichterte Priorisierungen bei der Auswahl und Verteilung von Ressourcen auf besonders kritische Anforderungen. Dabei hatten sie zur Unterstützung die Technik des Risikobasierten Testens eingesetzt. Mithilfe dieser Systematik war es nun ein Leichtes, Basismaße wie Überdeckungsgrade zur Verfügung zu stellen und diese in den Testberichten darzustellen. Auch das Zusammenstellen geeigneter Regressionstestsuiten war erheblich erleichtert worden, denn waren diese anfänglich noch in vertretbarer Zeit durchgelaufen, dauerte es bei dem umfangreichen Projekt irgendwann zu lange alle Tests immer wieder durchzuführen und es musste eine Auswahl getroffen werden. Diese richtete sich einerseits nach der Priorisierung der Anforderungen, andererseits nach den gerade durchgeführten Änderungen oder Erweiterungen des Funktionsumfanges.

Etwas Sorge bereitete ihm, ob der Fachbereich wohl ausreichend Zeit finden würde, durch ergänzende Testaktivitäten die Anforderungen im System zu validieren. Mitunter ergab sich in einer relativ spät angelegten Testphase noch Änderungsbedarf, weil wichtige Funktionen noch nicht vollständig durchdacht oder deren Auswirkungen auf andere Prozessschritte noch nicht klar genug herausgearbeitet worden waren. Das war in der Vergangenheit bei den komplexen Themen, für die sie die Anwendungen bauten, immer wieder aufgetreten und durch keine noch so sorgfältige Anforderungserhebung in Gänze zu vermeiden. Grundsätzlich versuchten sie diese Änderungen im Rahmen eines geordneten Releasemanagements in einem Update nachzuliefern. Dazu gab es dann einen Releaseletter, in dem die Änderungen oder Erweiterungen beschrieben und angekündigt wurden. So wurde niemand der Anwender überrascht und alle hatten hinreichend Zeit um sich vorzubereiten.

Er musste an eines seiner früheren Projekte zurückdenken, in dem das Thema Anforderungsmanagement noch unterbelichtet war. Dort waren die Anforderungen auf allen möglichen Wegen in das Projekt geströmt, befanden sich in Form von Excellisten, Worddokumenten, Memos und E-Mails oder schlicht und ergreifend nur in den Köpfen der Fachleute oder der Projektleitung. Das hatte regelmäßig dazu geführt, dass unmittelbar vor einer Auslieferung oder Inbetriebnahme Schwächen in den Anforderungen auffielen und diese mit hektischen Last-Minute-Fixes oder überhastet nachgeschobenen „Notfallauslieferungen" behoben werden mussten, was in Konsequenz oftmals zu erhöhten Fehlern und den damit verbundenen immensen Behebungskosten im Wirkbetrieb führte. An diese schlimmen Zeiten dachte er überhaupt nicht gerne zurück.

Vielleicht waren sie in ihrem Vorgehen noch nicht perfekt, aber was sie mit den vorhandenen Ressourcen hatten erledigen können, war geschehen. Auch in den nächsten Ausgaben der gefürchteten Fachzeitschrift würde ihr Projekt nicht als mahnendes Beispiel angeprangert werden.