Code zur Testautomatisierung sinnvoll und wartbar – Best Practices

Statt der Tücken von Record & Replay: Best Practices für die Entwicklung von Testsets zeigen, wie Sie den Code zur Testautomatisierung sinnvoll und wartbar aufbauen.

Code zur Testautomatisierung sinnvoll und wartbar aufbauen

Testautomatisierungswerkzeuge für Oberflächentests bringen viele Features mit sich, die die Entwicklung von Testsets beschleunigen können. Das prominenteste ist zweifelsohne die Record & Replay-Funktionalität, die Aktionen im Browser oder anderen Anwendungen aufzeichnet und für einen Testlauf erneut abspielen kann. In der Praxis führt die intensive Nutzung dieses Features allerdings schnell dazu, dass einem das Projekt über den Kopf wächst. Warum das so ist und was man dagegen tun kann, betrachten wir in diesem Blogpost näher.

Wie Testautomatisierungsprojekte häufig starten: Record & Replay

In Organisationen, die einen Testbereich aufbauen wollen, stellt sich schnell die Frage nach Testautomatisierung. Zum einen steigert dies die Effizienz bei der Ausführung des immer gleichen Tests, zum anderen wird das Personal häufig aus Fachbereichen herangezogen und soll das Testen nur "nebenbei" machen. Deshalb werden schnelle und einfache Lösungen gerne eingesetzt. Record-and-Replay-Funktionalitäten zeichnen Aktionen auf und können sie wieder abspielen, der erzeugte Code kann zunächst ignoriert werden. Diese Herangehensweise hat in unserem Fallbeispiel zwei große Vorteile:

1. Die Erzeugung der Testsets geht schnell. Gerade, wenn die Mitarbeiter:innen noch andere Aufgaben neben dem Testen haben, werden Funktionen, die die Automatisierung beschleunigen, dankbar angenommen.
2. Die Erzeugung setzt geringe technische Kenntnisse voraus. Weil der dahinterliegende Code zunächst ignoriert werden kann, braucht ein:e Mitarbeiter:in keine tieferen Kenntnisse in der Programmierung.

So läuft das Projekt an. Die Geschwindigkeit, mit der Tests automatisiert werden können, ist extrem hoch. Projektleiter:innen können freudig kommunizieren, wie schnell die Quote der automatisierten Testfälle ansteigt. Früher oder später kann die Stimmung allerdings kippen.

Record & Replay - Fünf häufige Probleme dieser Vorgehensweise

• Generierte Testsets sind anfällig für Fehler bei Veränderung in der getesteten Anwendung – Um einen Button oder ein Textfeld, mit dem interagiert werden soll, zu identifizieren, sind je nach Anwendungstyp Bezeichner notwendig (Bei Webseiten beispielsweise IDs, XPath oder CSS Selektoren). Diese können von den mehr oder minder intelligenten Recordern meist nicht sinnvoll erkannt werden. Beispielsweise kann ein Recorder nicht wissen, dass ein Linktext "2 weiter Angebote" kein verlässlicher Identifier für den Link ist, wenn sich die Anzahl der weiteren Angebote schon mal ändern kann. Ein Mensch (gerade Fachexpert:innen) wüsste das und könnte einen anderen Identifier wählen, z. B. die Position des Links in der HTML-Struktur der Seite.
  
  
• Keine sinnvolle Verwaltung von Testdaten – Allein die Logindaten eines:einer Testnutzers:Testnutzerin sind bei Aufzeichnung einzelner Testsets in jedem Testfall einzeln gepflegt. Ändert sich das Passwort des:der Nutzers:Nutzerin müssen alle Testests angepasst werden. Eine gezielte Entwicklung von Testsets erlaubt eine zentrale Testdatenverwaltung, wodurch Änderungen an nur einer Stelle vorgenommen werden müssen.
  
  
• Keine sinnvolle Modularisierung – Wenn sich der:die Tester:Testerin durch die Anwendung klickt, wird ein einziges langes Skript erzeugt. Wenn Anpassungsbedarf entsteht (z. B. wegen Punkt 1 oder 2), ist der Aufwand erheblich höher als bei "fachlich strukturiertem" Code. Wenn man z. B. beobachtet, dass die Suche nach einem Produkt nicht mehr funktioniert, geht das Auffinden der anzupassenden Stelle schneller, wenn man in der Funktion "Suche nach Produkt" mit zehn Kommandos suchen kann anstatt ein einziges langes Testset mit 300 Kommandos durchsuchen muss.
  
  
• Grenzen des Tools können nicht erweitert werden – Die meisten Testautomatisierungswerkzeuge bieten Möglichkeiten an, bei Grenzen der internen Funktionalitäten Code einzufügen, der komplexere Logik implementiert. Dieser Schritt ist je nach Umfang des Tests meist notwendig.
  
  
• Keine Validierungen – Beim Durchklicken merkt sich der Recorder die gemachten Aktionen. SOLL-IST-Vergleiche sind so nicht zu machen. Es wird lediglich geprüft, dass alle Buttons vorhanden sind und geklickt werden können, wodurch die Aussagekraft der Testsets stark reduziert wird.

Best Practices bei der Entwicklung von Testsets

Aus der Erfahrung mit unseren Testautomatisierungsprojekten im Kundenkontext haben wir eine Reihe von Best Practices entwickelt, die zu einem anhaltenden Projekterfolg beitragen können.

• Wählen Sie stabile Identifikatoren für Objekte, mit denen interagiert werden soll. – Gerade bei Webanwendungen führen meist viele Wege zum Ziel. Allerdings sind manche erheblich stabiler als andere.
  
  
• Kommentieren Sie den Code großzügig. – Gerade dort, wo komplexe Fachlichkeit implementiert wird, ist ein Verständnis nur so möglich. Wenn das verwendete Tool die Möglichkeit bietet, sollte zusätzlich Log-Ausgaben erzeugt werden, die ausgelesene Werte protokollieren. Dadurch werden tatsächliche Ergebnisse auch im Nachhinein nachvollziehbar.
  
  
• Setzen Sie Eingabewerte und Testdaten übersichtlich. – Bei Werten, die für den spezifischen Testfall gebraucht werden, bietet sich das Setzen von Variablen ganz zu Beginn des Testsets an. Bei Werten, die von mehreren Testsets verwendet werden, sollte eine Funktion geschrieben werden, die die gewünschten Werte von einem zentralen Ort ausließt. Treibender Faktor ist hier das Wissen, dass sich diese Werte häufig ändern können, man für die Anpassung allerdings wenig Zeit aufwenden möchte.
  
  
• Nutzen Sie Code-Implementierung sparsam. – Die meisten Tools bieten Möglichkeiten, Funktionalitäten in Code zu implementieren, beispielsweise in Groovy oder C#. Diese Codeschnipsel werden in der grafischen Oberfläche der Tools referenziert. Dabei ist darauf zu achten, dass der Code so kurz wie möglich ist. Gerade geübte Entwickler:innen neigen dazu, Teile in Code zu implementieren, die das Testautomatisierungstool auch in der grafischen Oberfläche realisieren kann. Dadurch wird es für ungeübte Nutzer:innen schwieriger zu bedienen.
  
  
• Streben Sie eine High-Level-Übersicht an. – In der obersten Abstraktionsebene sollte das Testset ähnlich gut lesbar sein wie ein Testfall in einem Testmanagementtool. Ausführung von einzelnen Klicks und Formulareingaben haben an der Stelle normalerweise nichts zu suchen.
  
  
• Benennen Sie Funktionen eindeutig, sodass sie die Funktion erklären. – Bei Namen wie "Lese Werte aus System A aus" kann sich ein:e naive:r Leser:in vorstellen, was dort passiert. Außerdem sollte darauf geachtet werden, dass die Benennung konsistent ist. Wenn als nächster Schritt "Werte aus System B auslesen und vergleichen" bricht das mit der Regel 'Verb zuerst' und mit der Granularität. Die erste Funktion ließt aus, die zweite ließt aus und macht einen Vergleich.
  
  
• Benennen Sie Variablen und Konstanten konsistent. – Per Konvention kann bei Bedarf weiter verfeinert werden, z. B. können Konstanten mit NUR_GROSSBUCHSTABEN geschrieben werden und Variablen als camelCase.
  
  
• Wählen Sie den Scope einer Funktion bevor Sie mit ihrer Implementierung beginnen. – Die ganz grobe Struktur wird in der Regel bereits von einem Testfall vorgegeben, der in einem Testmanagementtool beschrieben ist. An dieser kann man sich bei der Implementierung orientieren. Normalerweise behütet einen diese Vorgehensweise auch, dass die einzelnen Funktionen zu lang und damit unübersichtlich werden. Als Nebenprodukt dieses Schrittes ergibt sich bereits eine Modularisierung des Codes. Eine Funktion wie "Suche Kunden mit Kundennummer in System X" kann von anderen Entwickler:innen wiederverwendet werden, ohne dass sie das Rad neu erfinden müssen.
  
  
• Definieren Sie die Teststufe pro Testset. – Die Frage zielt auf das Testobjekt ab. Wird eine ganze Systemlandschaft End-to-End getestet, müssen Zugriffe auf alle beteiligten Systeme gewährleistet sein, was häufig mit großem organisatorischem Aufwand verbunden ist. Weil die Testsets dadurch sehr lang werden können, sind sie häufig instabiler als kleinere Testsets. Atomarer gebaute Testsets haben wiederum eine geringere Aussagekraft, weil sie nur Teilstrecken des Ganzen testen.
  
  
• Definieren Sie Testprozesse bevor mit der Automatisierung gestartet wird. – Der Wunsch nach Automatisierung drängt sich auf, wenn die dokumentierten Testfälle so unübersichtlich werden, dass sie nur mit großem Aufwand bei der Einarbeitung ausführbar werden. In dieser Phase mit der Automatisierung zu beginnen, führt nur zur Automatisierung dieses Chaos. Zunächst sollten Testfälle einheitlich strukturiert werden und auf Automatisierbarkeit geprüft werden. Testfälle, die unvollständig dokumentiert oder eine nicht-sinnvolle Struktur haben, müssen vor der Automatisierung aufgeräumt werden.
  
  
• Machen Sie sich bewusst, dass Automatisierung von Oberflächentests kein Allheilmittel ist. – Viel mehr ist es ein Baustein in der Teststrategie. Nach wie vor werden Fehler auch im Rahmen von Konzeption, Code Review und Unit Tests frühzeitig vermieden. Durch klare Kommunikation zum Beginn des Automatisierungsprojektes kann einem falschen Verständnis entgegengewirkt werden.

Als PDF immer griffbereit:
Die viadee Best Practices für die Entwicklung von Testsets.

Was heißt das für Ihr Testautomatisierungsprojekt?

Bei der Nutzung von schnellen und einfachen Lösungen werden unsere Best Practices stadardmäßig nicht eingehalten, sodass eher instabile Testsets entstehen und ein "Zusammenklicken nach dem Baukastenprinzip" in weite Ferne rückt. Nach einer kurzen Phase der Euphorie wegen des schnellen Voranschreitens in der Automatisierung ist ein Großteil der Kolleg:innen damit beschäftigt, kaputte Testfälle unter großem Zeitaufwand zu reparieren.

Deshalb empfiehlt es sich, bereits bei der initialen Erstellung darauf zu achten, dass

• ... dokumentierte Testfälle vorhanden sind. Nur mit ihrer Hilfe lassen sich defekte Testfälle wieder reparieren.
  
  
• ... Personal so weit geschult ist, dass es Testsets händisch implementieren kann – in der grafischen Oberfläche des Tools oder sogar in Code.
  
  
• ... vor der ersten Implementierung eine Codestruktur vereinbart wurde, an die sich alle halten. Beispielsweise "Konstanten für alle Testfälle sammeln wir in dieser Datei" oder "Schritte, die wir wiederverwenden könnten, sammeln wir in diesem Ordner".
  
  
• ... Code Reviews gemacht werden, sodass sichergestellt ist, dass ein Testset soweit verständlich ist, dass es andere Kolleg:innen reparieren könnten. Außerdem werden nur hier Fehler erkannt, wenn Validierungen nicht sauber implementiert sind. Im schlimmsten Fall wird sonst ein Testset ausgeführt, das niemals fehlschlagen kann, z. B. weil das Validierungskommando vergessen wurde oder versehentlich der IST- mit dem IST-Wert verglichen wurde. Testsets sind in diesem Fall effektiv wertlos, weil sie in der Implementierung immensen Aufwand verursacht haben, allerdings niemals in der Lage sind, Probleme in der Anwendung aufzudecken – ohne dass es jemals jemand merkt.
  
  
• ... Rahmenbedingungen vorhanden sind, um mit der Automatisierung zu starten. Dazu gehört ein strukturierter Testprozess und Qualitätssicherungsmaßnahmen auf vorhergehenden Teststufen. Wenn der Druck groß genug ist, kann an den Stellen auch parallel gearbeitet werden. Nach einer Analyse des IST-Prozesses kann die bewusste Entscheidung getroffen werden, einzelne Teststufen auszulassen.

An den genannten Punkten erkennt man bereits, dass Testautomatisierung kein triviales Thema ist. Verständlicherweise bewerben die Werkzeuganbieter wie schnell und sauber man ohne Programmierkenntnisse Tests mit ihnen automatisieren kann. Im Detail ergeben sich aber immer wieder sehr komplexe Fragestellungen, die für ein auf Dauer angelegtes Testautomatisierungsprojekt erfolgskritisch sind.

Wenn Sie für ein sauberes Aufsetzen Ihres Testautomatisierungsprojektes Unterstützung wünschen, steht Ihnen die viadee mit ihrem Inhouse-Kompetenzzentrum für Softwarequalitätssicherung natürlich zur Seite: Sowohl mit unserem hauseigenen Testautomatisierungstool mateo, als auch mit einer Reihe anderer Testautomatisierungswerkzeugen.

Als PDF immer griffbereit:
Die viadee Best Practices für die Entwicklung von Testsets.