Hierunter sind Tests aus Sicht und in der Verantwortung
der Anwender zu verstehen.
Daher geht es hier vorrangig um die Bereitstellung eines Mechanismus,
in dem die gewünschten Akzeptanztests formuliert
und ausgeführt werden können.
Es geht hierbei um die einfache Möglichkeit des
Nutzers die
fachlichen Anforderungen an das System so zu spezifizieren,
dass sich deren Erfüllung danach jederzeit automatisch überprüfen lässt.
Die Form dieser Spezifikation soll sich am gewünschten Ablauf der
Benutzeraktivitäten orientieren.
Die automatische Ausführung muss ein Ergebnis liefern,
das es dem Nutzer einfach macht, die Erfüllung oder auch Abweichungen zu erkennen.
Es muss also ein Format für solche Spezifikationen gegeben
sein und ein Mechanismus in den der Nutzer weitere
Spezifikationen einbinden kann, damit diese auf Knopfdruck
zusammen mit den bereits vorhandenen Spezifikationen
automatisch abgearbeitet werden.
Auch bestehende Spezifikationen müssen sich einfach verändern/erweitern lassen.
Die erfolgreiche Ausführung dieser Anforderungsspezifikationen
ist eine wesentliche Grundlage für die funktionale Abnahme des Systems.
Minimal müssen die Akzeptanztests es ermöglichen,
alle Benutzeraktivitäten am Bildschirm nachzubilden
(u.a. Eingaben in Maskenfelder, Auslösen von Schaltflächen oder Menüfunktionen,
Lesen von Maskenfeldinhalten - aus Einzelfeldern und Listen).
Damit wäre auch die Forderung nach Fernsteuerbarkeit und
Skriptfähigkeit weitgehend erfüllt.
Darüber hinaus sollten sich aber über diesen Mechanismus alle
Geschäftsprozesse und Geschäftsaktivitäten bis herunter
auf die Ebene der Teilprozesse, Prozessschritte, Arbeitsschritte und Einzelfunktionen
testen lassen, auch wenn diese vom Benutzer nur
indirekt über andere Geschäftsfunktionen ausgeführt werden können.
Diese höhere Granularität verbessert die Möglichkeit Fehler zu
lokalisieren (deren Ursache einzugrenzen) erheblich und ergibt eine
detailliertere Dokumentation der definierten Geschäftsabläufe.
Die von den Benutzern in der Anwendung direkt ausführbaren Funktionen werden
hier als Benutzerfunktionen bezeichnet.
Die übrigen Funktionalitäten die einen inhaltlichen Charakter
haben (im Gegensatz zu rein implementationstechnisch bedingten Funktionen/Methoden)
werden hier als Hauptfunktionen bezeichnet.
Wichtig ist in diesem Zusammenhang, dass auch alle Funktionen testbar sind,
die sich mit der Abgabe von Daten aus dem System oder der
Annahme von externen Daten befassen, wie z.B. Schnittstellen
und Auswertungen/Reports.
Bei Funktionen, die Daten aus dem System herausgeben, ist es oft sehr
mühsam diese technisch auf Einzelfeldebene zu überprüfen.
Hier kann die sog. Gold Master Technik helfen,
die sich auch bei Unit-Tests anwenden lässt.
Zuerst erzeugt das System in einem Test ein Ergebnis.
Dieses wird von Hand überprüft und dann in den Test zum zukünftigen automatischen
Vergleich eingebaut.
Ebenfalls muss über Akzeptanztests gesichert werden, dass korrekte externe Daten von einer
Schnittstelle auch akzeptiert und fehlerhafte Daten abgewiesen werden.
Technisch ist eine vollständige Testumgebung erforderlich, damit jeder dieser
Akzeptanztests auf einem definierten Anfangszustand aufsetzen kann, den der
Testmechanismus nach jedem Test schnell wieder herstellen können muss.
Dieses umfasst ggf. auch eine Testdatenbank, die mit möglichst
wenigen Stammdaten gefüllt wird,
damit die Eingabe von Testdatensätzen nicht an fehlenden gültigen Stammdaten scheitert.
Weitere, insbesondere Geschäftsdaten, sollte sie nicht
enthalten, damit die erwarteten Testergebnisse alleine aus
der Spezifikation des Tests erklärbar sind.
Die Qualität des Akzeptanztest-Mechanismus ist daran zu messen, in welchem Umfang (bis zu welcher Tiefe) Funktionalität in der Software über diesen Mechanismus getestet werden kann (d.h. nicht, dass die volle Tiefe auch genutzt werden muss !), wie selbsterklärend und in sich abgeschlossen die einzelnen Tests möglich sind und wie wenig Duplikation erforderlich ist, um eine gute Abdeckung zu erreichen.
Während sich die Benutzerfunktionen aus der Bedienoberfläche ergeben,
sind die Hauptfunktionen im Rahmen der Anforderungsspezifikation
zu definieren.
Es sind im wesentlichen alle Funktionalitäten, für die der Nutzer
konkrete, überprüfbare Funktionsregeln abnehmen möchte.
Die inhaltliche Qualität der konkreten Tests liegt zwangsläufig
in der Verantwortung des Nutzers – auch wenn ihn der
Anbieter
bei der Erstellung unterstützt.
Die folgenden Referenzen stellen kein Qualitätsurteil dar.
Sie sollen nur einen ersten Einstieg in Aspekte der Materie bieten.
Als Basis für automatisierte Akzeptanztests wird heute oft das
in diverse Programmiersprachen übertragene
Framework Fit
genutzt (s.a. FitNesse).
Dieses enthält auch diverse Beispiele.
Speziell zum Fernsteuern und Testen von Java Swing Applikationen
steht auch das auf FitNesse basierende
JeFF
zur Verfügung.
Die Tests werden z.B. in einer Textverarbeitung mit angemessenen
Beschreibungen als gekennzeichnete Tabellen formuliert
und dann als HTML-Seiten abgespeichert.
In diesen Tabellen werden Funktionsparameter,
Benutzereingaben, -aktionen und die
erwarteten Ergebnisse festgelegt.
Nach Ausführung erhält man die selben Seiten zurück.
Dabei werden bei den erfolgreichen Tests die Ergebnisse
grün und bei den erfolglosen rot hinterlegt
und dem erwarteten ein abweichendes geliefertes Ergebnis
gegenüber gestellt.
So lassen sich auch Irrtümer bei den Vorgaben leichter erkennen.
fitnesse
ist eine aktive, internationale Diskussionsgruppe
mit hochkarätigen Teilnehmern.
Als Literaturhinweis sei hier nur erwähnt:
An weiterer Literatur existieren zur Zeit nur einzelne Kapitel in Büchern
über das Testen, Konferenzvorträge und
Tutorien z.B. von Universitäten.
Diese lassen sich über obige Webseiten oder eine Internetsuche
(z.B.: fit acceptance testing) leicht finden.
Hinweise zur Gold Master Technik sind in vielen
Büchern zur Testautomatisierung zu finden.