Die Entwicklung mit automatisierten Komponententests (auch als automatisierte Unit Tests - AUTs bekannt) ermöglicht ein modernes und beschleunigtes Projektvorgehen. Das liegt massgeblich an den folgenden drei Eigenschaften von Komponententests:
- es wird für die Testausführung kein Transport in das Q-System benötigt
- auf der Granularität von Komponenten können Test Design Verfahren angewandt werden, die eine vollständige Testabdeckung ermöglichen
- es wird mit minimalsten Simulationsdaten und nicht mit Massendaten des Systems gearbeitet
Das ideale Projektvorgehen sieht wie folgt aus:
Am Praxisbeispiel der DSO Umsetzung soll das Vorgehen nun verdeutlicht werden.
Erstes Meeting mit dem Fachbereich
In dem zweistündigem Termin wurde dem Fachbereich das Ihm noch unbekannte xGile Testportal vorgestellt, die Idee dahinter erklärt und wie ein Testfall angelegt wird. Überraschenderweise wurden sofort Fehler in den hinterlegten Erwartungen der bestehenden Testfälle indentifiziert. Ein Schlüsselerlebnis. Nicht nur hat der Fachbereich das Testvorgehen verstanden, er hat auch sofort Fehler in der Testfalldefinitioen aus der Entwicklung heraus erkannt. Die Erkenntnisse waren eindeutig. Der Fachbereich ist in der Lage das Testvorgehen ohne Probleme zu verstehen und die Testfälle im Detail zu validieren. Verständnisprobleme sind damit Geschichte und wurden wie in dem Fall gleich korrigiert.
Als ich die Testfallerwartung gleich geändert hatte und den Testfall ausführte, meldete dieser natürlich einen Fehler. Ich öffnete die HANA Prozedur, passte das Coding schnell an und führte den Testfall wieder aus. Der Testfall war erfolgreich und die Anforderung erfüllt. Eine Sache die nur fünf Minuten dauerte und die wir im Meeting gemeinsam durchführten, um zu zeigen wie das grundsätzliche Vorgehen ist. Den Kommentar vom Leiter des Forderungsmanagement werde ich nie vergessen, der bis dahin kein Wort von sich gab und den ich dachte nur gelangweilt zu haben: "Wer baut denn sowas? Das ist ja genial!".
Bereits am nächsten Tag wuchs die Anzahl der Testfälle ohne mein dazutun um weitere 6 Testfälle auf 17 Testfälle an. Wir hätten initial ein Test Design durchführen müssen, aber ich war mehr als zufrieden das der Fachbereich eifrig selbst testet, die Test Design Session zur Ermittlung der optimalen Anzahl der Testfälle holten wir später nach. Für den Moment war es ein reiner Erfolg alle im Boot zu haben.
“Der Fachbereich testete aktiv mit und vertraute dem Testvorgehen und Ergebnissen.”
xGile Testen
Binnen einer Woche war alles fertig entwickelt und testautomatisiert. Im Ergebnis 138 Zeilen Code und 22 xGile Testfälle auf Testdaten, vom Fachbereich damit automatisch abgenommen! Alle Tests waren erfogreich und der erste Transport in das Q-System stand an. Hier schaute der Fachbereich manuell nach Ausreissern. Es wurden hohe Abweichungen entdeckt und der Fehler identifiziert: Gutschriftendie in negativen Umsätzen mündeten. Diese Anforderung war initial nicht bedacht und musste noch implementiert werden. Dafür wurde wieder ein xGile Testfall im Entwicklungssystem erstellt und damit das Problem nachgestellt. Es bedurfte nur 3 Zeilen an Testdaten um die Fehlersituation nachzustellen. Shaka! Die Anforderung war nun hinterlegt und es wurde solange entwickelt bis der Testfall und damit die Anforderung erfolgreich abgenommen wurde. Dann wurden alle Testfälle ausgeführt um zu zeigen das keine bestehenden Testfälle / Anforderungen korumpiert wurden. Erst dann fand der zweite Transport in das Q-system statt und erst jetzt wurde der Fachbereich wieder gebeten Querschecks auf Realdaten durchzuführen. Fazit vom Fachbereich danach:
“Am meisten hat mich begeistert, das einmal gefundene Fehler nicht mehr auftreten können.”
Fachbereich Forderungsmanagement zum xGile Testen
Nach Produktivnahme des Codes wurden bis heute (3 Jahre später) keine Fehler mehr identifiziert. Ein Fakt der für den Gütegrad des Testvorgehens spricht. Die Entwicklungen wurden längst an andere Kollegen übergeben, ohne Probleme, denn mein ganzes Wissen und das des Fachbereiches liegt in 22 automatischen Testfällen. Nachträgliche Änderungen können mit diesem Sicherheitsnetz einfach und schnell durchgeführt werden.
Der finanzielle Wert
Wie kann man den finanziellen Wert der Automatisierung berechnen? Um dies zu beantworten, berechnen wir den Automatisierungsfaktor der Aufwände. Dieser lag bei ca. 70%.
Der Automatisierungsfaktor ist damit 70% geteilt durch 30% = 2,3. Dieser Faktor wird nun mit den 9 Manntagen multipliziert, die für die manuelle Testarbeit im Q-System aufgewendet wurden. Wir müssen auch die 1,5 Manntage abziehen, die für die Erstellung der automatisierten Tests mit xGile investiert wurden und man erhält:
= 2,3 * 9 MD - 1,5MD = 19,2 MD eingespart !
Das bedeutet, bei jeder Ausführung der 22 xGile Test werden 19,2 Manntage eingespart! Unter der Annahme eines Tagessatzes von 700 $ würde dies zu Einsparungen führen von:
700 € * 19,2 = 13.444,0 € bei jeder Ausführung !
Sicherlich sind Sie über den Wert überrascht, aber die Wahrheit ist, daß manuelles eben so Testen teuer ist, daß es im Tagesgeschäft nie umfänglich durchgeführt wird und es daher nur bei Stichprobentests bleibt.
Das ist der wirkliche Grund, warum Sie ohne eine Testautomatisierung so schlechte Berichtsergebnisse erhalten.
Zusammenfassung
Das Testens fand maßgeblich auf dem Entwicklungsystem statt. Für den Fachbereich ist das xGile Testportal einfach zu bedienen und nachzuvollziehen. Seine Beteiligung erhöht nicht nur den Qualitätsgrad und die Geschwindigkeit sondern reduziert auch seine finale Mitwirkzeit durch eine automatisierte Validierung und Abnahme. Sein Vertauen in das Testvorgehen ist gestärkt und es findet kein Schattentesten mehr statt. Am Ende wurden in der Produktion keine Fehler mehr identifiziert. Es entstand ein Sicherheitsnetz für zukünftige Änderungen das bei jeder Ausführung 19,2 Manntage, ca. 13.444,0 € einspart.
