Projekte in der Krise II

Über Testmanagement und Qualitätsansprüche

Nachdem ich im ersten Teil dieser Serie davon geschrieben habe, wie wichtig gute Projektinitialisierung ist kommen wir im zweiten Teil auf einen Dauerbrenner. Das Testmanagement. Ich möchte diesen Teil relativ früh in der Serie bringen, obwohl die Entscheidung dafür bei den Tests zu sparen oft sehr spät fällt. Wieso? Weil es einer der häufigsten Missstände ist und oft sowohl von den Lieferanten als auch den Kunden als der Punkt angesehen wird, bei dem man schnell mal 20 % Budget einsparen kann. Ein Trugschluss, wie sich oft zeigt.

Aber von Anfang. Das Projekt ist gestartet, die Voraussetzungen gut. Zwar sind die Anforderungen etwas nebulös, aber wir haben im Vertrag einen guten Grundstock gelegt. Konzeption, Realisierung, Test und Abnahme. Alle Phasen vorhanden und als Milestones definiert. Das Zeitfester ist gerade ausreichend. Die Mitarbeiter sind für Ihre Jobs qualifiziert und haben sich auf Ihre Aufgaben committed. Die Konzeption findet direkt mit dem Kunden statt und erstmals definiert der Kunde wirklich, was er sich unter den einzelnen Punkten vorstellt. Der Nebel verschwindet und Klarheit kehrt ein. Langsam wird klar, dass das Projekt an der ein oder anderen Stelle deutlich komplexer ist als angenommen. Zum Teil verstecken sich die entsprechenden Anmerkungen in Nebensätzen der Ausschreibung, zum Teil wurde einfach vergessen die entsprechenden Bereiche abzugrenzen. Der Kunde weigert sich mehr Budget bereitzustellen, da diese Anforderungen aus seiner Sicht Kern-Bestandteil der Anwendung sind. Was nun? Der Projektleiter möchte den Kunden nicht verärgern und dieser hat Jahresziele auf dieser Applikation und möchte bei seinem Vorstand nicht schlecht dastehen, indem er mehr Budget aushandelt. Man geht also gemeinsam durch das Konzept und identifiziert schließlich einen großen Block, der nicht wirklich etwas zum Projekt beiträgt. Das Testmanagement!

Natürlich fordert der Vorstand einen entsprechenden Bericht von dem Projekt. Schließlich ist das ja eine wichtige Vorgabe aus dem V-Modell! Da das Projekt natürlich agil läuft hat sich der Vorstand letzten Ends darauf eingelassen, dass ein einzelner Testbericht erstellt wird. Aber der muss dann umfänglich sein.

Die Projektsteuerung aus Kunde und Lieferant kommt auf eine einfache Lösung. Das Testmanagement in der geplanten, strukturierten Form mit Unit-Tests, Testfällen und eigenem Integrationstest wird gestrichen. Stattdessen sollen die Entwickler ihren Code testen und die Ergebnisse in einem Excel zusammenfassen. Am Ende wird so ein Testbericht entstehen, der alle Bereiche umfasst und somit klar den Anforderungen des Vorstandes entspricht. Ursprünglich waren 20% für Testmanagement eingeplant. Nun konnte es auf 5% reduziert werden. Die Ersparnisse werden ausreichen um das Projekt umzusetzen und sogar noch etwas Puffer überlassen um ein paar Bugs mehr zu beheben, die diesem Vorgehen geschuldet sind.

Das Projekt läuft gut an. Die Kollegen sind zufrieden die lästigen Tests los zu sein und arbeiten schnell und effektiv die Aufgaben ab. Als weiteren Einsparungseffekt hat man auf Sprintplanung und -abschluss verzichtet. Gelegentlich zeigt man dem Projektleiter und dem Kunden einen zwischenstand und diese wirken auch soweit zufrieden. Ab und zu treten Bugs während dieser Vorführung auf. Diese werden jedoch immer bis zur nächsten Vorstellung beseitigt.

Schließlich erreicht das Projekt einen Stand, in dem die ersten Testbenutzer des Kunden auf das System kommen. Und schnell stellt sich die Ernüchterung ein. Zwar funktionieren alle Module so, wie sie vom Entwickler entwickelt wurden, doch einige gingen einfach komplett an der Anforderung vorbei. Andere erfüllen zwar ihre Aufgabe, doch bei der ersten Fehleingabe entstehen völlig unnütze Daten oder das System katapultiert sich in einen undefinierten Zustand. Auch fachliche Defizite werden schnell wieder offenkundig, da der Projektleiter des Kunden zwar weiß worum es in der Anwendung ging, er selbst jedoch nicht aus der Fachabteilung kommt, sondern Teil der IT ist. Schnell werden Fragen laut. Warum wurde die Fachseite in die Erstellung der Tests nicht involviert? Wie wurde denn dies oder jenes überhaupt getestet? Natürlich wurde das neue Testvorgehen nicht schriftlich fixiert, da es ja unter dem Radar laufen sollte und nun passiert das, was zu erwarten war. Der Projektverantwortliche auf Kundenseite zieht seinen Kopf aus der Schlinge und beruft sich auf das Angebot. Dort steht ja ganz klar etwas von der Erstellung von Testfällen für die einzelnen Testschritte der Testphase.

Das Ganze eskaliert. Der Projektverantwortliche des Kunden wird abgezogen und ein Projektteam übernimmt die Fertigstellung. Es stellt sich heraus, dass das Projekt einige schwerwiegende Punkte falsch oder unzureichend implementiert hat. Die Fehlerrate ist überdurchschnittlich hoch und Testergebnisse sind nicht nachvollziehbar. Der Lieferant bangt um Folgeaufträge, da es sich um einen wichtigen Kunden handelt und verspricht die Missstände zu beseitigen. Es wird sich darauf verständigt die fehlenden Tests nicht mehr nachzuholen und die Bugs im Eskalationsmodus zu beheben. Ein Testteam des Kunden wird aus der Fachabteilung zusammengestellt und die Fehler gefunden und behoben. Das Budget war bereits vorher stark strapaziert und für Bugfixing bleiben lediglich 5 % über, die nun deutlich überschritten werden. Insgesamt belaufen sich die Mehraufwände auf weitere 15 % und das Projekt hat damit die Grenze der Wirtschaftlichkeit erreicht. Beide Parteien bringen das Projekt zu Ende. Die fertiggestellte Applikation ist lauffähig. Leider nicht so performant wie erhofft, denn dafür hat unter dem Strich die Zeit gefehlt. Änderungen sind teuer, da man sich immer durch den Code der Eskalationsphase quälen muss, welcher natürlich mit der heißen Nadel gestricht wurde. Durch das fehlen von Unit-Tests sind auch nachfolgende Änderungen nicht ohne Risiko und Fehler schleichen sich immer wieder ein, die auch die Wirtschaftlichkeit der Änderungen immer wieder gefährdet. Unter dem Strich kann dieses Projekt zwar als Erfolg, jedoch nicht als Glanztat gewertet werden und jeder Entwickler stöhnt leise auf, wenn wieder eine Änderung daran stattfinden soll oder ein Bug aus alter Zeit doch noch aufgrund von Gewährleistungsansprüchen gelöst werden muss.

Hätte all das verhindert werden können? Meiner Meinung nach ja. Und auch wenn in diesem Beispiel mehr Faktoren als nur das Testmanagement eine Rolle gespielt haben, ist es doch dieser Punkt auf den ich mich konzentrieren möchte. Weitere Faktoren waren sicherlich bereits im Angebot mit fehlenden Abgrenzungen und unzureichenden Fachkenntnissen, oder auch das knappe Budget der Kundenseite. Beides lässt sich nicht so einfach abstellen aber ich werde diese Themen in einem späteren Beitrag sicherlich noch einmal ausführlich behandeln.

Warum sollten wir Testmanagement betreiben? Ich denke, es wurde deutlich. Testmanagement umfasst viele verschiedene Aspekte mit dem gleichen Ziel. Die Anforderungen des Kunden möglichst scharf zu zeichnen, diese durch den Kunden abnehmen zu lassen und anschließend genau gegen diese Anforderungen zu entwickeln und das Ergebnis anhand dieser Anforderungen zu verifizieren. Wie kann das funktionieren? Nun, als erstes haben wir einen Wunsch von einem Kunden. Im Agilen Prozess nennen wir das einmal Feature. Jedes Feature besteht aus einer Anzahl an Anforderungen oder Use-Cases oder User-Stories, welche alle umgesetzt werden müssen, damit der Kunde das Feature benutzten kann. Beispielsweise könnte das Feature eine Kontaktverwaltung sein. Die einzelnen Use-Cases sind dann Anlegen, Löschen, Bearbeiten, Anzeigen, Exportieren etc. Jeder Use-Case hat dann noch Vorgaben. So genannte Abnahmekriterien. Abnahmekriterien für die Anlage können Pflichtfelder, Validierungen, Designvorgaben oder Ansprechzeiten sein.

481cd1a2-bf0c-4c03-a9e8-87d81bf15e91tests%20pro%20artefakt

Und genau dieser Struktur stellen wir nun unsere Tests gegenüber. Beispielsweise werden für die Akzeptanzkriterien entsprechende Unit-Tests erstellt. Für die Anlage der Pflichtfelder prüfen wir wie sich das Feld verhält, wenn es ausgefüllt wurde, wenn es nicht ausgefüllt wurde und wenn in ein Zahlenfeld Text eingetragen wird. Entsprechen alle Testergebnisse unseren Erwartungen, können wir davon ausgehen, dass das Akzeptanzkriterium damit erfüllt ist.

Nun schreiben wir noch einen Oberflächen-Test für den Endnutzer. Dort sollten wir die Akzeptanzkriterien berücksichtigen. Also etwa lege einen Eintrag an. Prüfe dabei ob die Pflichtfelder richtig dargestellt werden. Prüfe ob die Validierungen greifen, prüfe ob die Designvorgaben stimmen. Prüfe ob die Reaktionszeit im gewünschten Bereich liegt. All das kann in einem oder in mehreren Testfällen geschrieben werden. Da dieses Beispiel tatsächlich alles die Anlage behandelt würde ich alles zusammen in einen Test schreiben. Würde es Anlegen und Löschen behandeln wären es 2, usw.

Als letztes machen wir unseren Integrationstest und prüfen damit, ob unser neu erstelltes Feature auch zu den restlichen Komponenten passt. Das kann bspw. dann interessant werden, wenn der Kontakt als Referenz zu einem Kunden dient oder für Veranstaltungen. Wir führen also alle Tests unserer Use Cases nun gemeinsam auf der Integrationsumgebung aus.

All diese Arbeit erfüllt 4 Ziele. Erstens, durch die Untergliederung der Features bis hinunter zu Akzeptanzkriterien haben wir eine Anforderungsebene erreicht, auf der sich auch der Entwickler wohl fühlt und genau weiß was er machen muss, damit das Feature umgesetzt werden kann.

Zweitens, der Kunde versteht bei dieser Untergliederung den Zusammenhang zwischen seinem Feature und den Akzeptanzkriterien des Entwicklers und kann anhand dieser Abstufung verstehen was er da genau vor sich stehen hat und auch was er von der fertigen Anwendung erwarten kann.

Drittens, durch dieses Verständnis kann der Kunde die Akzeptanzkriterien freigeben, bevor die eigentliche Entwicklung startet. Damit haben wir die Sicherheit, dass wir die Anforderung richtig verstanden haben und wir haben eine konkrete Liste bei der wir sagen „Lieber Kunde, das waren die konkreten Anforderungen, die wir umgesetzt haben. Nichts links, nichts rechts davon. Wenn jetzt etwas fehlt ist das ein Change.“ Das gibt uns Planungssicherheit.

Und schließlich viertens, durch die Erstellung, Ausführung und Protokollierung der Tests erhalten wir die Sicherheit, dass die Anwendung tut was sie soll und der Kunde erhält die Sicherheit, dass wir auch alle Akzeptanzkriterien und damit schlussendlich das Feature vollständig umgesetzt haben.

Und somit erreichen wir unser eigentliches Ziel. Wir setzen genau das um, was der Kunde fordert und zwar so, wie es besprochen war. Die Missverständlichen Features wurden in einfach verständliche Akzeptanzkriterien heruntergebrochen. Natürlich macht das alles Mehraufwände. Doch wir sparen am Ende die Zeit bei der Fehlerbehebung und der Nacharbeit wegen falschen oder fehlenden Schritten wieder ein. Leider ist Testmanagement immer eine Gefühlssache, da man natürlich nicht messen kann, wie viel Zeit man dadurch gespart oder mehr verbraucht hat. Währen die guten Ergebnisse mit Testmanagement auch ohne erreichbar gewesen? Ich sage, vielleicht. Aber nur dann, wenn es sich um einen stark standardisierten Prozess handelt und jeder beteiligte über großes Fachwissen verfügt. Für einen Dienstleister im Projektgeschäft halte ich es für nicht realistisch und dementsprechend das Testmanagement für unabdingbar.

Mehr zum Thema?

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s