Wenn ich in der Kaffeeküche von meinem aktuellen Projekt erzähle, höre ich oft die Frage, ob die Vielzahl an manuellen Tests, die wir verwenden, noch zeitgemäß sei. Insbesondere die jüngeren Kollegen, die im Geist der allgegenwärtigen Testautomatisierung ausgebildet wurden, wundern sich über dieses Vorgehen.
Manuelles Testen bleibt wichtig
Warum sind also manuelle Tests noch notwendig? Meine Projekterfahrungen der letzten 25 Jahre zeigen, dass in jedem Projekt oberhalb einer gewissen Komplexität manuelle Tests verwendet werden. Die Gründe hierfür sind vielfältig.
Am häufigsten liegt das an der Datenkomplexität: In jedem nicht-trivialen Datenmodell gibt es eine Vielzahl von Abhängigkeiten und Varianten, die oftmals nur schwer in künstlichen Testfällen abgebildet werden können. Hinzu kommen oft noch querschnittliche Aspekte wie datenbezogene Berechtigungen, die es zusätzlich erschweren, künstliche Testdaten zu erstellen. Ein einfacherer Weg ist deshalb meist die Verwendung von Produktions- oder produktionsnahen Daten.
Das Problem bei dieser Art von Testdaten tritt dann zutage, wenn es sich bei den Tests um Daten verändernde Tests handelt. Um für diese Testszenarien wiederholbare Tests zu erreichen, sind in der Regel aufwendige Undo-Mechanismen beziehungsweise ein Neu-Aufbau oder Import der Datenbank erforderlich. Aufgrund der Größe von produktionsnahen Datenbeständen ist dies entweder sehr zeitaufwendig oder schlicht nicht realisierbar.
Ein weiterer Aspekt, der in bestimmten Fällen gegen automatisierte Tests spricht, ist eine komplexe Vergleichslogik zur Ermittlung des Testergebnisses. Insbesondere beim Testen von grafischen Benutzeroberflächen wird die Wartung und Pflege von automatisierten Tests regelmäßig zum Aufwandstreiber. Soll neben der Funktionalität einer GUI auch noch die Darstellung am Bildschirm – von Entwicklern gerne auch „Pixelschieben“ genannt – getestet werden, ist aus meiner Erfahrung ein automatisiertes Testverfahren nicht mehr realisierbar.
Entwickler sind auch Tester
In diesem Artikel werde ich einige einfache Techniken vorstellen, die den Testern das Leben erleichtern. Dazu möchte ich aber zunächst einmal den Begriff Tester etwas weiter fassen. In der klassischen Literatur zum Thema Testing umfasst die Rolle des Testers einen der Entwicklung eines Softwaresystems eher nachgelagerten Bereich.
Die in diesem Beitrag verwendete Definition geht weiter. Unter einem Tester verstehe ich jede Person, die während der Entwicklungsphase eines Softwaresystems mit diesem zum Zweck der Qualitätssicherung interagiert. Dies umfasst insbesondere auch die Softwareentwickler, die von ihnen entwickelte Features in der Regel auch durch Interaktion mit dem System testen („Ich klick mich mal schnell durch“). Man könnte also von Entwickler-Testern und Tester-Testern sprechen.
Warum ist diese Erweiterung des Begriffs des Testers wichtig? Sie ist deshalb wichtig, weil sie uns die Begründung liefert, weshalb wir manuelle Tests möglichst gut unterstützen sollten.
Effizienz spart Geld
Die Entwickler sind in der Regel diejenigen Projektbeteiligten, die – neben der Verwendung von automatisierten Tests – am häufigsten mit dem System in Form von manuellen Tests interagieren. Aus diesem Grund ist für sie am wichtigsten, dass diese manuellen Tests effizient durchführbar sind. Jeder zusätzliche Klick und jede zusätzliche Eingabe kosten Zeit und lenken von der eigentlichen Aufgabe ab.
Durch die Reduktion von repetitiven Tätigkeiten wird der manuelle Test für den Tester wesentlich angenehmer. So steigen die Chancen, dass diese Tests öfter durchgeführt und auch mehr Fehler gefunden werden. Außerdem sollte man nicht vernachlässigen, dass durch eine gute Unterstützung von manuellen Tests weniger Fehler bei der Testdurchführung passieren und damit die Anzahl der Fehlalarme sinkt.
Die meisten der hier vorgestellten Techniken habe ich in meinen Projekten zunächst für mich selbst eingebaut, weil ich schlichtweg zu faul bin, immer wiederkehrende Schritte erneut manuell durchzuführen. Insgesamt ist dies eine bei manuellen Tests häufig anzutreffende Situation: Der Weg hin zum eigentlichen Testfall ist wesentlich aufwendiger als die Durchführung der Tests selbst.
Bitte nicht nachmachen!
Bevor wir nun zum eigentlichen Inhalt des Artikels kommen noch ein Wort der Warnung: Die hier vorgestellten Ideen sind für nicht-produktive Szenarien gedacht. Sie folgen in der Regel einem 80:20-Ansatz. Das bedeutet, dass nicht alle möglichen Anwendungsfälle abgedeckt werden, sondern nur diejenigen, die sich mit einem geringen Aufwand umsetzen lassen.
Darüber hinaus ist es ratsam, die vorgestellten Ideen über globale Schalter oder ähnliches abzusichern. Dies vermeidet auch einen unkontrollierbaren Aufwand, wenn nicht angeforderte Funktionen plötzlich vom Kunden für gut befunden und dann unterstützt werden müssen. Einige der vorgestellten Ideen eignen sich dennoch gut als Showcases, die dem Kunden in der Testumgebung vorgestellt werden können, um Vorschläge für eine verbesserte Anwenderunterstützung zu machen.
Fünf Tipps zur Unterstützung manueller Tests
In den nachfolgenden Abschnitten werde ich nun einige Beispiele präsentieren, wie manuelle Tests unterstützt werden können. Die einzelnen Vorschläge mögen teilweise trivial klingen und der Leser mag sich fragen, warum er oder sie für solche Binsenweisheiten wertvolle Zeit geopfert hat. Ich kann Ihnen nur empfehlen: Probieren Sie die ein oder andere Kleinigkeit aus und sehen Sie selbst, ob es hilft. Es müssen nicht immer die ganz großen Räder in Form komplexer Testmethoden sein, die ein Projekt voranbringen. Manchmal entstehen Fortschritte schon dank kleiner Rollen.
Zur Verdeutlichung der einzelnen Ideen werde ich immer wieder auf mein aktuelles Projekt zurückgreifen. Es handelt sich hierbei um ein Werkzeug zur Testplanung von elektrischen und elektronischen Komponenten in Fahrzeugen. Aufgrund der hohen Variantenzahl und der komplexen zeitlichen Zusammenhänge beim Fahrzeugbau ist auch ein Werkzeug zur Testplanung sehr komplex.
Import/Export von Testdaten aus Datenbanken
Wie bereits erwähnt, ist die Bereitstellung von Testdaten ein zentraler Aspekt beim Testen einer Anwendung. Die erste Regel für die Bereitstellung von Testdaten lautet daher: Schnell! Der Austausch des Testdatenbestands einer Anwendung soll es dem Tester ermöglichen, verschiedene Szenarien bereitzuhalten und einfach zwischen diesen wechseln zu können.
Je nach verwendeter Datenbank können hierzu teils einfach die zugrunde liegenden Dateien ausgetauscht oder von der Datenbank angebotene Import-/Export-Mechanismen verwendet werden. Beim Import/Export über Werkzeuge empfiehlt es sich, darüber hinaus zu prüfen, ob die Menge der Daten leicht reduziert werden kann. In meinem aktuellen System konnte ich messen, dass über 90 Prozent der Laufzeit beim Import auf Audit-Tabellen entfällt, die für die Testfälle in der Regel nicht relevant sind. Durch das Ausfiltern dieser Datensätze konnte also die für den Import benötigte Zeit auf 10 Prozent der ursprünglichen Laufzeit reduziert werden.
Welche Techniken zum Austausch der Daten auch immer verwendet werden, das Wichtigste ist die zweite Regel: Automatisch! Beim Wechseln des Datenbestands sollten möglichst wenig manuelle Schritte notwendig sein. Normalerweise lässt sich das schon recht einfach mit einem Kommandozeilen-Skript oder einer Funktion um das Build-Skript erreichen.
Beim Austausch der gesamten Datenbank werden vom Tester angelegte Datensätze normalerweise überschrieben und müssen dann wieder neu angelegt werden. Hier sollte man die Tester fragen, ob bestimmte Informationen vor einem Austausch der Datenbank gesichert und anschließend wiederhergestellt werden sollten.
In unserer Anwendung waren dies unter anderem die Filtereinstellungen: Jeder Benutzer kann im System mehrere Filter definieren, die dann auf die Daten angewendet werden können. Die Tester verwenden diese Filter, um einzelne Szenarien abzubilden ohne durch die Menge an Daten überwältigt zu werden. Da diese Filtereinstellungen in der Datenbank gespeichert werden, sind die Einstellungen nach dem Einspielen eines aktuellen Datenbankbestands verloren.
Hier konnten wir die Tester unterstützen, indem wir eine Funktion zum Exportieren und Importieren von Filtern in der Anwendung anbieten. Diese zunächst nur für die Testunterstützung implementierte Funktion hat schließlich auch den Weg in den aktuellen Softwarestand gefunden.
Nach jedem Testfall den Ursprungszustand herstellen
In komplexen Testszenarien kommt es gelegentlich vor, dass die Durchführung eines Tests die Daten so verändert, dass für einen erneuten Durchlauf andere Testdaten benötigt werden. Um das erfolgreiche Ausführen eines solchen Testfalls prüfen zu können, kann eine Technik aus dem Bereich des automatisierten Tests angewendet werden. Hierfür wird dem Tester eine Möglichkeit bereitgestellt, eine auszuführende Funktion mit einem Rollback-Flag zu kennzeichnen. Damit wird nach der Ausführung der Aktion der ursprüngliche Zustand wiederhergestellt. Wie dies genau umgesetzt werden kann, hängt natürlich von der konkreten Anwendung ab; im einfachsten Fall wird anstatt eines Datenbank-Commits einfach ein Rollback ausgeführt.
Manchmal ist es beim Testen einer Anwendung notwendig, Fehlerszenarien zu testen, die eigentlich nicht direkt testbar sind. Ein typisches Beispiel hierfür sind Validierungen im Backend für Eingaben, die im Frontend schon verhindert werden – etwa durch Verwendung von spezifischen HTML5-Eingabeelementen. Hier kann es sehr hilfreich sein, eine kleine Funktion bereitzustellen, die diese Eingabeprüfung aufseiten des Frontends deaktiviert, sodass die eigentlich nicht möglichen Eingaben nun doch möglich sind. Dies erlaubt es dem Tester, die Validierungslogik zu testen – ohne auf aufwendige Verfahren wie Request-Manipulation oder manuelle HTTP-Requests zurückgreifen zu müssen.
Holzauge, sei wachsam: Fehlerlokalisierung durch Nummerierung
Um Fehler zu beheben, ist es hilfreich, möglichst genau zu wissen, wo und wann diese aufgetreten sind. Bei der Dokumentation von Fehlern können wir den Tester gut unterstützen. Diesen Datensätzen eindeutige Nummern zu geben – in Datenbankanwendungen ist dies in der Regel der Primärschlüssel – macht es sehr einfach, die Datensätze zu identifizieren, bei denen Fehler auftreten. Diese Information kann versteckt in der Anwendung hinterlegt werden, sodass der Tester mühelos den Datensatz identifizieren kann, ohne diesen beschreiben zu müssen („Beim Kunden XYZ, wohnhaft in …“).
Die Kommunikation über Fehler lässt sich zudem sehr leicht über die Vergabe von Fehler-Ids verbessern. Hiermit sind nicht Fehlernummern gemeint, die eine Fehlersituation beschreiben, sondern vielmehr Ids für konkret aufgetretene Fehler. In meiner aktuellen Anwendung erzeugt jede Exception automatisch einen Universally Unique Identifier (UUID), der zusammen mit dem Fehlertext in die Log-Datei geschrieben wird. Mithilfe dieser Id ist es dann ein Leichtes, die entsprechende Stelle in der Log-Datei zu finden, ohne zum Beispiel über Zeitstempel suchen zu müssen.
Für erfahrene Tester und insbesondere die Entwickler sind möglichst leicht einsehbare Log-Dateien wichtig. Sofern die Anwendung nicht auf dem lokalen Rechner läuft, ist es oftmals nicht direkt möglich, Log-Dateien anzusehen. Mit einfachen Mitteln kann ein Logfile Viewer in die Anwendung integriert werden, der es dem Tester erlaubt, die Log-Informationen direkt aus der Anwendung heraus zu sehen.
Diese Technik sollte natürlich nicht in produktiven Umgebungen angewendet werden. Auch in reinen Test- oder Integrationsumgebungen ist in der Regel eine Abstimmung mit dem Anwendungsbetrieb notwendig.
Speed-Coding: Automatisierung der (für den Testfall unwichtigen) Eingaben
Es gibt viele einfache Hilfsmittel, um die zeitlichen Aufwände für den Aufbau der jeweiligen Testszenarien zu reduzieren. In meinem aktuellen System gibt es beispielsweise viele Funktionen, die vor der Ausführung die Eingabe eines Kommentars erfordern. Dieser Kommentar ist aber für die Durchführung eines manuellen Tests in der Regel nicht relevant.
Aus diesem Grund haben wir die GUI zur Eingabe des Kommentars so erweitert, dass ein Doppelklick auf das Eingabefeld einen Standard-Kommentar erzeugt und gleichzeitig die Schaltfläche zum Schließen des Dialogs ausführt. Das klingt nach nicht viel, erleichtert aber das Testen dieser Funktionen ungemein, da der Wechsel von der Maus zur Tastatur und wieder zurück entfällt.
Eine ebenso einfache wie effektive Methode, Eingaben zu beschleunigen, ist eine Funktion zum automatischen Expandieren von Buchstaben. So führt in meinem aktuellen Projekt die Eingabe von „Lorem:100“ zum Auffüllen des Eingabefeldes mit genau 100 Zeichen, was zum Beispiel Feldlängen-Validierungen sehr leicht testbar macht.
Bei Webanwendungen bieten URL-Parameter eine weitere, einfache Unterstützung für den Aufbau von Testszenarien an. So lassen sich beispielsweise Vorbelegungen für Eingabefelder als URL-Parameter hinterlegen und die Anwendung übernimmt die Werte beim Aufruf der URL.
Im aktuellen Projekt verwende ich diese Möglichkeit, um Anmeldedaten in der URL zu speichern und so ganz einfach zwischen verschiedenen Benutzern und Rollen wechseln zu können. Diese Möglichkeit besteht aus Sicherheitsgründen natürlich ausschließlich in der Testumgebung.
Scripting: Teilautomatisierung von manuellen Tests
Der letzte Tipp zur Erleichterung des manuellen Testens, den ich vorstellen möchte, beschreibt Techniken zum Teilautomatisieren von manuellen Tests. Wie bereits des Öfteren in diesem Artikel erwähnt, ist der Weg zum eigentlichen Testfall meist aufwendiger als die Durchführung des Testfalls selbst. Der Tester kann durch Automatisierungswerkzeuge gut unterstützt werden.
Zum einen kann dies durch den Einbau einer Scripting-Engine in die Anwendung erreicht werden. Dies eröffnet dem Tester vielfältige Möglichkeiten, allerdings sind hierfür Programmierkenntnisse erforderlich, und von daher richtet sich diese Technik eher an die Entwickler-Tester als an die Tester-Tester.
Zum anderen können generische Automatisierungswerkzeuge zum Aufbau einer anwendungsspezifischen Testinfrastruktur verwendet werden. In einem früheren Projekt haben wir ein System zur Testfallbeschreibung entwickelt, aus dem heraus ausführbare Automatisierungsskripte erzeugt wurden. Diese Skripte konnten mithilfe einer selbst gebauten Ausführungsmaschine auf Basis der JavaRobot-Klasse als Vorbereitung eines manuellen Testfalls ausgeführt werden. Der Vorteil einer Eigenentwicklung lag in diesem Fall darin, dass wir so anwendungsspezifische Szenarien wesentlich besser abdecken konnten als mit generischen Standard-Werkzeugen.
Zusammenfassung
In diesem Beitrag habe ich einige einfache Ansätze skizziert, die das manuelle Testen von Anwendungen unterstützen. Viele der hier vorgestellten Tipps erscheinen trivial und offensichtlich; dennoch findet man solche Funktionen relativ selten im Test-Setup von Anwendungen. Aus diesem Grund möchte ich Sie bitten, diesen Beitrag als Anregung zu nehmen, um darüber nachzudenken, wie Tester mit kostengünstigen Mitteln unterstützt werden können.
Es muss nicht immer ein Enterprise-Testing-Framework her, um die Arbeit zu erleichtern. Vielmehr reichen oft schon ein paar einfache, aber effektive Methoden.
