Skip to main content

Neue Freiheiten durch Keyword-Driven Testing

Verfasst von Christoph Jacobs   //  

In einer perfekten Welt erfolgt die Qualitätssicherung parallel zur Softwareentwicklung. Die Testfälle werden nach reiner Lehre schon vor dem Entstehen der Anwendung erstellt. Das sieht im realen Leben meist deutlich anders aus. Noch! Es gibt eine Methode, die diese Vision zum Leben erweckt.

Im Bereich der agilen Vorgehensmodelle haben sich in der Vergangenheit Lösungsansätze für Softwaretests entwickelt, die diese Problematik ganzheitlich angehen. Wie beispielsweise die „testgetriebene Entwicklung“.

Dieser, oft auch „Test First“ genannte Idee, setzt die Testfallerstellung strikt an den Beginn der eigentlichen Entwicklerarbeit. Bevor die Programmierer ihre Funktionen und Komponenten entwickeln, werden Softwaretests gebaut. Diese dienen als zu erfüllendes Kriterium, gegen das „anprogrammiert“ wird.

Dabei fällt eine Sache auf: Es sind meist Entwickler, die die Tests schreiben oder als Tester agieren. Das tun sie in ihrer Entwicklungsumgebung, mit ihrer Programmiersprache und ihrer Erfahrung. Tester mit fachlichem Hintergrund tun sich schwer, selbst wenn sie eine entsprechende Technik-Affinität aufweisen.

Hier kann die Methode des „Keyword Driven Tests“ Abhilfe schaffen. Erstmals 2006 in einer Master-Arbeit eines finnischen Studenten von „Nokia Siemens Networks“ genauer und mit Tool-Bezug beschrieben, stellt sie grundsätzlich eine Mittelweg zwischen Technik und Fachlichkeit dar, um Testfälle und Testszenarien zu erstellen.

Der Name der Methode weist schon auf eine zentrale Komponente des Ansatzes hin: Schlüsselwörter. Um die große Bedeutung und den Aufbau dieser Schlüsselwörter besser zu verstehen, hilft ein Ausflug in die Welt der klassischen Testallerstellung: Hierbei werden aus einer Fachspezifikation, einem DV-Konzept oder aus definierten Anforderungen klassische Testfälle erstellt.

Diese sind in der Regel:

  • statisch
  • mehr ausformulierte Prosatexte als konkrete Anweisung
  • jede neue Funktionalität bekommt einen oder mehrere Testfälle zugewiesen
  • die Testfälle sind mal mehr, mal weniger ausführlich – haben also mal einen Testschritt, mal zehn
  • Vor- und Nachbedingungen sind, wenn es gut läuft, pro Testfall festgelegt

Ein Testschritt, der die Anmeldung an einer Web-Anwendung beschreibt, sieht dann so aus: „Der Bediener gibt in das Feld ‚Benutzer‘ seine Benutzerkennung und im Feld ‚Passwort‘ sein Kennwort ein und drückt anschließend Enter oder die Login-Schaltfläche“.

Werden mehrere Szenarien im Vorfeld einer Anmeldung benötigen, bedient man sich klassischerweise Copy & Paste. Sind Änderungen an dieser Komponente zum aktuellen oder späteren Release notwendig, muss der Testfall aufwendig mehrfach geändert werden.

Auch beim „Freien Testen“ müssen die Schritte, die zum Fehler führten, in neue Testschritte „gegossen“ werden. Der Nachtest soll ja schließlich strukturiert und nach Vorgaben verlaufen. Die Dauer der Testdurchführung hängt davon ab, wie schnell man jeden Schritt gelesen und verstanden hat. Und, von einem möglichen Automatisierungsansatz Ihrer Tests sind Sie mit diesem Vorgehen sehr weit entfernt!

Keep it short!

Mit Schlüsselwörtern sieht das Szenario so aus:

Eingabe xyz123 im Feld ‚Benutzer‘

Diese technische Notation bildet kurz und knapp ab, was genau zu tun ist. Und schafft den Spagat zwischen technischer Anweisung und menschen-lesbarer Information. Für Keyword Driven Tests existiert dabei folgende Leitidee:

  1. Operation to perform: „Eingabe“

  2. The values: „xyz123“

  3. Name of the GUI item: Feld „Benutzer“

Die „operation to perform“ sind die eigentlichen Keywords, die vorgeben was zu tun ist. Hinter jedem Begriff muss immer die gleiche Aktionen stecken. Bei „Eingabe“ wird ein Eingabefeld erwartet, bei „Klick“ ein Button und bei „Prüfung“ wird etwas validiert, manuell oder automatisch.

„The values“ sind die Werte, die eingegeben werden sollen. Sie sind der variabelste Teil der Tests. Abstrakt betrachtet sind es die Parameter der Tests. Sie sollten beim Aufbau der Tests auch immer mit Default-Werten versehen werden, um schnell neue Tests erstellen zu können.

„Name of the GUI-item“ sind Testobjekte der untersten Ebene: Eingabefelder, Auswahllisten, Schaltflächen, Maskenelemente. Im Idealfall liegt bereits eine vorhandene Bibliothek bzw. Liste aller Elemente vor.

Das vorher genannte Anmelde-Beispiel kann nun um den fehlenden Schritt ergänzt werden: Eingabe <akt.Kennwort> im Feld „Passwort“. Klick Schaltfläche „Login“.

Aus einem längeren Prosa-Testfall sind mit Hilfe von Keywords drei knappe Testschritte geworden. Schnell ist erkennbar worauf die Idee hinausläuft: Baukastenprinzip. Die Keyword-Testschritte können flexibel und beliebig miteinander kombiniert werden.

Einigt man sich auf eine feste Anzahl von Stichwörtern, entsteht eine Bibliothek von kleinen Testschritten, die jedem beteiligten Tester und Test-Designer bekannt ist. In den zusammengestellten Testfällen wird auf die vorhandenen Keyword-Testschritte referenziert.

Die Vorteile der Methode

Schnelleres Test-Design: Durch die Zusammenstellung vorhandener Keyword-Testschritte sind neue oder veränderte Testfälle schnell erstellt.

Schnellere Testdurchführung: Ein Keyword steht immer für eine bestimmte Aktion. Der Tester liest und handelt schneller und kennt irgendwann alle zentralen Keywords Bessere

Wartbarkeit: Änderungen an der Anwendung bedürfen nur der Änderung der betroffenen Keyword-Testschritte. Das Durchsuchen ganzer Testfälle nach betroffenen Stellen entfällt.

Keine Redundanzen: GUI-Elemente sind in einer Bibliothek vorhanden, mögliche Übergabewerte werden parametrisiert, Aktionen mit Keywords indiziert. Durch das Baukastenprinzip und die Referenzen wird nichts doppelt gepflegt.

Weniger Komplexität: Das Verfahren zwingt zu einer strukturierten und formalisierten Auseinandersetzung mit dem Testobjekt. In der subjektiven Wahrnehmung des Test-Designers sinkt die Komplexität der Anwendung.

Risikobasierte Testdurchführung: Die konsequente Zuordnung von Fehlern zu Testschritten steuert auf Basis vergangener Tests, welcher Teil des Testobjekts zuerst getestet wird.

Leichtere Automatisierung: Der zentrale Vorteil der Methode ist die starke Ausrichtung auf Automatisierung der Testfälle.

Die Keywords bieten die technische Grundlage, um eine automatische Durchführung einzelner Testschritte zu realisieren unabhängig von der verwendeten Automatisierungstechnik bzw. -programmiersprache. Mittlerweile existieren Tools auf dem Markt, die mit ihren Adaptern das Bindeglied zwischen den fachlichen Keywords und den auszuführenden technischen Aktionen darstellen.

In der Praxis darf man aber keine Wunder erwarten: Der initiale Aufwand zur Schaffung einer Keyword-Bibliothek ist hoch. Die Ausgestaltung darf nicht zu detailliert sein, aber auch nicht zu abstrakt, um möglichst schnell konkrete Testfälle abzuleiten.

Insbesondere klassische fachliche Abnahmetests unter Beteiligung des Kunden gestalten sich aufwendiger. Nicht selten werden „Test-Drehbücher“ erwartet, die die Testfälle doch wieder in Prosaform enthalten.

Alles in allem bietet das Keyword Driven Testing aber sowohl für technisch als auch für fachlich orientierte Mitarbeiter einen mächtigen, streng-strukturierten und tool-unabhängigen Ansatz des modularen Testfall-Designs.