Automatisierungsprogramm

Das Automatiserungsprogramm am Anwendungssystem hat als zentrale Aufgaben:

• das Anwendungssystem betrieblich anzusprechen
• alle Aktionen zu dokumentieren, d.h.
  • Schritte zu protokollieren
  • Ergebnisse abzulegen
• eine Auswertung zu treffen

Auf dem Markt vorhandene Testsoftware bzw. Testframeworks bieten Hilfen für Standard-Anwendungen an. Sie sind auf die unterschiedlichen qualitativen Anforderungen und Teststufen ausgerichtet, so gibt es auf Komponentenebene Unit-Frameworks, es gibt diverse Treiber für Last- und Performancetest und es gibt viele Frameworks für funktionale Tests insbesondere über GUIs. Bei allen Framework muss für die konkrete Anwendung Anpassungsarbeit betrieben werden, oft mit Skripten.

Bei schlüsselwort-getriebene Frameworks wie Cucumber ist die Spezifikation in einer programmähnlichen Sprache verfasst (anstelle der Programmfunktionen werden Schlüsselwörter verwendet, die dem Anwendungskontext näher kommen - das könnte auch ein eigenes Programm-Interface anbieten, zumal die Implementierung hierzu ohnehin in einer Klasse erfolgen muss).

An selbst zu erstellende Skripte kommt man bei einer Testautomatisierung also kaum vorbei. Die Frage ist also nur, wie weit man für die eigene Automatisierung vorhandene Frameworks nutzen kann. Im Konkreten muss man somit selbst schauen, ob vorhandene Frameworks einem Arbeit abnehmen können. Da eine GUI-Testautomatisierung aufwendig ist und hierzu Frameworks am ehesten Unterstützung anbieten, sollte man diese auch nutzen. Es bleibt dennoch die "Übersetzungsarbeit" von der fachlichen Spezifikation auf das Testframework. Bei professionellen Frameworks kann eventuell ein Mapping gescannter technischer Schnittstellen reichen. Bei schlüsselwort-getriebenen Frameworks müssten die Tests separat geskriptet werden, eventuell kann ein Mapper erstellt werden, der eine spezifikationsfreundliche Excel-Datei in ein Skript übersetzt.

Grundaufbau eines schlüsselwort-getriebenen Skripts wie Cucumber:

10 Given geladenes Testszenario   # hier ist Vorbereitungsarbeit zu leisten, damit der Server ein bestimmte Seite bereitstellt
20 When Benutzer-Eingabe          # hierzu muss die GUI abgebildet werden
30 Then Benutzer-Ausgabe          # die GUI-Abbildung 
40 ...                            # gab es für diesen Schritt eine Client-Server-Interaktion?
50 When Button                    # vermutlich mit Client-Server-Interaktion
60 Then nächste Seite             # Return-Code: hat Server die Client-Aktion entgegengenommen?
70 ???                            # was wurde im Server verarbeitet?

Das kommentierte Pseudo-Skript soll die Frage verdeutlichen: Was soll getestet werden:

(a) nur der Client - dann braucht man sich um Zeile 70ff nicht zu kümmern,

(b) Interaktion Client-Server - dann muss die Server-Verarbeitung ab Zeile 70 getestet werden

(c) vor allem Server-Verarbeitung - dann muss die Client-Wirkung auf den Server getestet werden, also beispielsweise der Unterschied zwischen Zeile 10 und 70 auf dem Server.

Die Option c dürfte die wahrscheinlichste sein, denn die Client-Interaktion stellt oft eine notwendige Interaktion innerhalb der Gesamtverarbeitung auf dem Server dar. Und schließlich gilt ja, auch wenn eine Anwendung sich noch so benutzerfreundlich darstellen soll, das Geschäft wird auf dem Server gemacht! Und die Entwickler wie auch die Tester werden im Endeffekt von diesem Geschäft bezahlt, und nicht von den vielen Clients.

Die qualitativen Anforderungen an selbst erstellte Automatisierungsskripte - auf welcher Ebene auch immer - sind selbstverständlich geringer als an die Anforderung selbst. Denn im Unterschied zur Anwendung selbst wirkt sich ein Fehler nicht direkt auf den Anwendungsbetrieb aus. "nicht direkt" heißt: ein erkannter Automatisierungsfehler ist kein Anwendungsfehler. Das bedeutet, dass Tester das Ergebnis des Automatisierungprogramm selbstkritisch betrachten sollten: ein angezeigter Fehler kann auf einen Automatisierungsfehler hinweisen oder auf einen Anwendungsfehler. Schlimmer wäre die Konstellation, dass ein Automatisierungsprogramm keinen Fehler anzeigt, obwohl ein Fehler vorhanden ist -  der würde nämlich unerkannt in Produktion kommen, Um das Automatisierungsergebnis selbstkritisch betrachten zu können, muss das Ergebnis ausführlich dokumentiert werden - eine rot-grün-Ampel reicht da nicht.

Testautomatisierung - Anforderung

Eine Testautomatisierung sollte gegenüber den unterschiedlichen Akteuren und Stakeholdern folgende Anforderungen erfüllen:

• Berichte gegenüber Projektleitung
• Anwendungsabdeckung gegenüber Fachbereiche und Projektleitung
• technisch passend hinsichtlich dem Testobjekt
• einfache Testspezifikation in Terstfällen für fachliche Testanalyse und -spezifikation
• automatische Durchführung
• Ablaufdokumentation für Recherche, um ggf. Fehler nachzuweisen
• Wiederholbarkeit für Regressionen
• automatisierte Auswertung

Testorganisation

Die Organisation des Tests kann sowohl intern betrachtet werden, d.h. welche Rollen wer im Test hat, als auch als Teil des Projektes, d.h. wie der Test in der Gesamtstruktur verortet ist.

Test innerhalb Auftrags-/Projektstruktur

Wie der Test in der Projektstruktur verortet ist, soll anhand des V-Modells diskutiert werden. Dabei ist ein entscheidendes Kriterium, ob und welche Projektaufgaben innerhalb des Unternehmens erfolgen.

Die unterschiedlichen Konstellationen wirken sich auf den Aufgabenumfang des funktionalen Tests aus, wobei sich der funktionale Test vorwiegend auf Systemebene befindet.

a) bei Eigenproduktion sind die Wege innerhalb des Unternehmens üblicherweise kurz und kollegial. Die Disziplinen Businessanalyse, Implementierern und Test kann so in einem crossfunktionalen Projektteam zusammengefasst sein. Dadurch können die Softwarestände unmittelbar getestet werden und teamintern abgenommen werden. Für jedes Release muss eine ausreichend umfassende Menge von Testfällen aus allen Entwicklungsphasen und Anwendungsteilen nur wiederholt werden, um zu gewährleisten, dass die Anwendung stabil deployt ist.

 b) beim SW-Gewerkauftrag wird die eigentliche Software durch eine Fremdfirma implementiert. Hierbei muss zur Beauftragung einerseits ein Lastenheft mit den Anforderungen erstellt werden und andererseits ein Pflichtenheft mit der Umsetzung, die zumindest beschreibt, wie die Anwendung zu bedienen ist. Für die Umsetzung wird es mindestens eine Projektorganisation auf Seiten der Auftragserstellung geben, um den Auftrag zufriedenstellend umzusetzen. Diese koordiniert die eigene Businessanalyse, Implementierung und SW-Test bis an die definierten Systemgrenzen. Dieser SW-Test des Autragnehmers sollte so umfassend die Software testen, dass sie anstandslos im beauftragten Rahmen betrieben werden kann. Ob man davon ausgehen kann, sollten auf Seiten des Auftraggebers verschiedene eigene Tests ermitteln. Gegebenenfalls muss auf Seiten des Auftraggebers ein separater Testauftrag für den SW-Test vergeben werden, der wiederum extern beauftragt oder selbst durchgeführt wird.

Es kann daneben auch eine Projektorganisation auf Seiten des Auftraggebers aufgebaut werden, um die SW-Entwicklung enger zu begleiten.

Testrealisierung - Automatisierung