10 Best Practices: #3 Einfach wartbare Tests

Ein gut strukturierter Testfall wird weniger Wartungsaufwand mit sich bringen.
Identifizieren Sie zuerst alle Funktionen, die getestet werden sollen. Dann brechen Sie jeden Test für diese Funktionen auf eine Reihe von einfachen Schritten herunter, mit einer klaren Definition des erwarteten Ergebnisses. Erst dann sollten Sie entscheiden, welche Tests manuell und welche automatisiert ausgeführt werden sollen. Mehr Informationen dazu finden Sie im ersten Artikel dieser Serie, in dem behandelt wird, welche Testfälle automatisiert werden sollten. 

Vollständige Dokumentation von Testfällen trägt zu gut strukturierten Testfällen bei, da so für alle die Vorbedingungen, auszuführenden Schritte und erwarteten Ergebnisse nachvollziehbar und überprüfbar sind. Testfallvorlagen oder Testmanagementtools wie TestRail sind nützliche Hilfsmittel zur Erstellung von Testfalldokumentation. 

Idealerweise sollte ein Testfall eine einzige Funktion überprüfen und nur aus einem einzigen definierten Grund fehlschlagen. Komplexe Testfälle neigen eher zu Instabilität. Wenn ein Testfall viele Schritte umfasst, kann es sinnvoll sein, die Aktionen auf zwei oder mehr Testfälle aufzuteilen. 

Die Namen von UI-Elementen und Testobjekten sollten selbsterklärend sein. Wenn zusätzliche Kommentare nötig sind, um einen Testfall oder -schritt zu dokumentieren, dann kann das auf zu große Komplexität hindeuten. 

Ein Testfall sollte unabhängig von anderen ausführbar sein. Testfälle sollten also so wenig wie möglich von den Ergebnissen vorhergehender Testfälle abhängig sein. Zum Beispiel sollte ein Testfall für den Zahlungsprozess eines Webshops nicht von einem vorhergehenden Testfall abhängig sein, der prüft, ob das Hinzufügen von Artikeln zum Warenkorb funktioniert. Voneinander unabhängige Testfälle erleichtern die Wartung und ermöglichen es Ihnen außerdem, von paralleler bzw. verteilter Ausführung zu profitieren. Wenn eine Abhängigkeit allerdings unvermeidlich ist, verwenden Sie die verfügbaren Features Ihres Testautomatisierungsframeworks, um sicherzustellen, dass alle Testfälle in der richtigen Reihenfolge ausgeführt werden.
 

Tests, die auch bei UI-Änderungen weiterhin funktionieren, sind einfacher zu warten. Verlassen Sie sich daher nicht auf Bildschirmkoordinaten zur Erkennung von UI-Elementen. Bei Webanwendungen sollten Sie sich außerdem weder auf die HTML-Struktur der Seite, noch auf dynamische IDs verlassen. Idealerweise sollten die UI-Elemente Ihrer Anwendung schon in der Entwicklung mit einzigartigen IDs versehen werden. Das vereinfacht die Objektauffindung und macht Tests robuster. Leider kann dem aber nicht immer nachgekommen werden. Deswegen wendet unser Objekterkennungstool Ranorex Spy automatisch Best Practices bei der Identifizierung von UI-Elementen an, um Ihre Tests so robust wie möglich zu gestalten. 

Gliedern Sie Ihre Testfälle nach dem Funktionsbereich der AUT, den sie abdecken. Das erleichtert die Aktualisierung von verwandten Testfällen, wenn ein Funktionsbereich von Änderungen betroffen ist. Außerdem können Sie so Teilregressionstests für diesen Funktionsbereich ausführen. In Ranorex Studio können Sie wiederverwendbare Codemethoden erstellen und in einer Bibliothek speichern. Dort können Sie die Methoden einer Sammlung für einen bestimmten Funktionsbereich hinzufügen. Sowohl Methoden als auch Sammlungen können mit Beschreibungen versehen werden, die in der Bibliothek sichtbar sind und Testern dabei helfen, die richtige Methode auszuwählen. 

Wiederholen Sie nicht dieselben Schritte in mehreren Tests. Sammeln Sie sie stattdessen in wiederverwendbaren Modulen. Sie sollten z.B. nur ein Modul haben, das Ihre AUT startet. Dieses können Sie dann in anderen Testfällen wiederverwenden. Falls sich dann am Startprozess der AUT etwas ändert, müssen Sie nur das Originalmodul aktualisieren. Mit seiner Unterstützung von schlüsselwortgetriebenen Tests, lokalen und globalen Parameters und Bedingungen eignet sich Ranorex Studio besonders zur einfachen Erstellung von ausgefeilten Testfällen basierend auf einzelnen, wiederverwendbaren Testmodulen. 

Schreiben Sie Testdaten nicht direkt in Ihren Code. Verwalten Sie sie stattdessen in einer externen Tabelle oder Datenbank und referenzieren Sie dann diese über Variablen und Parameter. Mehr zu datengetriebenem Testen finden Sie im Ranorex User Guide. 

Entwickler nutzen Source-Control-Tools wie Git, Subversion und Microsoft TFS, um gemeinsam Code zu entwickeln und gegebenenfalls einfach auf frühere Versionen zurückzufallen. Wenn möglich sollten Sie zur Verwaltung Ihres Testcodes dasselbe Source-Control-System wie zur Anwendungsentwicklung verwenden. 

Unzuverlässige Server oder Netzwerkverbindungen können zu Testfehlschlägen führen. Ziehen Sie die Verwendung von Mockservern in Betracht, um Fehlerpotential zu eliminieren, das nicht mit der AUT zusammenhängt. 

Verwenden Sie Setupprozesse, um Vorbedingungen für Tests zu verwalten und so sicherzustellen, dass die AUT im gewünschten Zustand für die Testausführung ist. Ein Setupprozess umfasst normalerweise: Start der AUT, Login, Laden der Testdaten und andere für den Test nötige Vorbereitungen. Verwenden Sie Teardownprozesse, um die AUT zum Ausgangszustand für den nächsten Testlauf zurückzusetzen, bspw. durch Bereinigung der AUT von allen eingegebenen Testdaten. 

Fail-Fast ist ein Schlüsselkonzept in der Testgestaltung. Es besagt, dass Fehlschläge nur so viel Zeit in Anspruch nehmen sollten wie nötig. Wenn also ein ernsthaftes Problem vorliegt, bei dem ein Anhalten des Tests vorgesehen ist, sollte dieses sofort identifiziert und berichtet werden, anstatt den Test noch weiter mit dem Fehler laufen zu lassen. Setzen Sie außerdem vernünftige Werte für Zeitbeschränkungen, damit Ihr Test nicht ewig nach unauffindbaren UI-Elementen sucht. 

Ihr Test sollte nur dann als Ganzes fehlschlagen, wenn dies nötig ist. Einen Test bspw. nach nur einem Fehler zu stoppen kann wertvolle Zeit verschwenden. Außerdem erfahren Sie so nicht, ob die anderen Testfälle durchgelaufen wären. Zu diesem Zweck stellt Ihnen Ranorex Studio neben dem einfachen Stoppen des Tests noch drei weitere Optionen betreffend Fehlerverhalten zur Verfügung: continue with iteration (weiter mit nächster Iteration), continue with sibling (weiter mit nächstem Testfall auf gleicher Ebene) und continue with parent (weiter mit nächstem Testfall auf übergeordneter Ebene). Mehr dazu finden Sie im Ranorex User Guide. 

Führen Sie nur jene Tests aus, von denen Sie erwarten, dass sie erfolgreich sein werden. Tests, die einen Defekt abdecken, der noch nicht behoben ist, sollten aus dem Haupttestlauf entfernt werden und separat ausgeführt werden. Dadurch lässt sich einfacher erkennen, ob im Haupttestlauf Probleme vorhanden sind. Ebenso sollten Sie auch mit instabilen Tests vorgehen. Testen Sie diese dann manuell.  

Konfigurieren Sie Ihre automatisierten Tests so, dass Sie Screenshots aufzeichnen und verwenden Sie das Reporting, um detaillierte Informationen zur Fehlerbehebung zu erhalten. Ranorex Studio bietet einen sogenannten maintenance mode, der es Ihnen erlaubt, einen Testlauf zu pausieren, um Fehler zu diagnostizieren und direkt zu beheben. In diesem Screencast können Sie den Maintenance Mode in Aktion sehen: