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.