10 Best Practices: #1 Was soll man automatisieren?

Automatisierte Tests für instabile Features können oft zu hohen Wartungskosten führen. Solange also ein Feature noch in Entwicklung ist, sollten die dazugehörigen Tests manuell ausgeführt werden.

Ein Regressionstest ist ein Test, den das getestete System bereits in einem früheren Entwicklungszyklus erfolgreich durchlaufen hat und der bei Modifikationen an der Software wieder durchgeführt wird. Das hilft sicherzustellen, dass durch Änderungen ihm Rahmen eines neuen Releases weder alte Bugs erneut auftreten, noch neue hinzukommen. Da Regressionstests einen starken Wiederholungscharakter haben und häufig ausgeführt werden, sollten sie meist noch vor allen anderen Tests automatisiert werden. Mehr zu Regressionstests erfahren Sie in unserem Ranorex Regression Testing Guide.

Führen Sie eine Risikoanalyse durch und automatisieren Sie die Tests für jene Features, die das größte Risiko bergen, welche also bei Fehlschlag am meisten Kosten verursachen würden. Binden Sie diese automatisierten Tests dann auch in Ihre Regressionstests ein. Mehr zur Priorisierung von Test Cases nach ihrem Risiko finden Sie in der Sektion Risk assessment  im Ranorex GUI Testing Guide.

Je nach Anzahl und Umfang Ihrer Regressionstests kann es sinnvoll sein, nicht alle Regressionstests bei jedem neuen Build auszuführen. Smoke Tests sind eine Unterkategorie von Regressionstests. Sie dienen dazu, zu überprüfen, ob ein neuer Build solide ist, bevor Zeit in weitere Tests investiert wird. Typische Checks in Smoke Test sind z.B., ob die Anwendung startet, man sich einloggen kann und verschiedene Schlüsselfunktionen korrekt arbeiten. Smoke Tests sollten Teil Ihres Continuous-Integration-Prozesses (CI) sein und bei jedem neuen Build automatisch getriggert werden.

Jeder Test, der Wiederholungscharakter hat, eignet sich besonders zur Automatisierung. Datengetriebene Tests sind hierfür ein Paradebeispiel. Anstatt bei jedem Durchlauf manuell verschiedene Datensets wie Benutzername, Passwort, E-Mail, Zahlungsart usw. einzugeben, um diese Felder zu validieren, bietet es sich an, diesen Prozess zu automatisieren. Wie man richtig datengetriebene Tests erstellt, wird in einem späteren Artikel in dieser Serie thematisiert.

Lasttests können als eine Unterart von datengetriebenen Tests angesehen werden. Sie überprüfen, wie das System auf eine bestimmte theoretische Last reagiert. Diese Last lässt sich simulieren, indem man einen datengetriebenen Test mit einem Tool kombiniert, das den Test parallel bzw. auf einem Grid verteilt in mehreren Iterationen ausführen kann.

Mit Cross-Browser-Tests lässt sich sicherstellen, dass eine Webanwendung unabhängig vom verwendeten Browser bzw. der Browserversion korrekt arbeitet. Normalerweise ist es nicht nötig, alle Tests auf sämtlichen Browser- und Geräte-Kombinationen durchzuführen. Stattdessen reicht es üblicherweise, sich auf die Risikofeatures und die zur Zeit gängigsten Browserversionen zu konzentrieren. Gegenwärtig ist Google Chrome der am meisten verwendete Browser auf Desktop- und Mobilplattformen. Auf Tablets nimmt Chrome den zweiten Platz hinter Safari ein. Angesichts dieser Informationen wäre es also sinnvoll, für Chrome sämtliche Features zu testen und für Safari, Firefox, Internet Explorer und Microsoft Edge nur die Risikofeatures.

Mobile Apps müssen auf einer Vielzahl von Geräten mit unterschiedlichen Leistungsprofilen, Auflösungen und Betriebssystemen funktionieren. Einem Bericht von Software Testing News zufolge müsste ein neu gegründetes Testlabor fast 50 verschiedene Geräte anschaffen, um 80 % der 2018 möglichen Kombinationen mit manuellen Tests abzudecken. Durch die Automatisierung von Cross-Device-Tests lassen sich diese Anschaffungen umgehen und noch Zeit in der Testausführung sparen.

Bei manchen automatisierten Tests kommen mehrere verschiedene Technologien zum Einsatz, beispielsweise bei Hybrid-Apps oder bei einer Web-App mit einer Datenbank im Backend. Um End-to-End-Tests in solchen Umgebungen einfacher zu gestalten, sollte am besten ein Automatisierungsframework implementiert werden, das sämtliche verwendeten Technologien unterstützt. Ob Ranorex Ihre Technologieanforderungen unterstützt, können Sie auf der Seite Unterstützte Technologien in Erfahrung bringen.

Es gibt viele Arten von dynamischen Inhalten, wie zum Beispiel Internetseiten, die sich abhängig von Benutzereinstellungen verändern; PDF-Dokumente oder Datenbankeinträge. Das Testen von solchen Inhalten gestaltet sich besonders herausfordernd, da der aktuelle Zustand des Inhalts zum Zeitpunkt der Testausführung nicht immer bekannt ist. Mehr zu diesem Thema erfahren Sie im Blogartikel Automated Testing and Dynamic IDs.

Automatisierte Tests können fehlschlagen, wenn ein erwarteter Zustand nicht bzw. nicht sofort eintritt. Es ist daher wichtig, im Test so mit Wartezeiten umzugehen, dass dieser nicht direkt fehlschlägt, nur weil das System langsamer als sonst reagiert. Gleichzeitig muss aber auch sichergestellt sein, dass der Test fehlschlägt, wenn nach einer sinnvoll gewählten Zeitspanne nichts geschieht. Mehr zum Thema Konfiguration von Wartezeiten in Ranorex erfahren Sie im User Guide in der Sektion Action properties.

Ähnlich wie beim Warten auf Ereignisse können automatisierte Tests aufgrund von unerwarteten Benachrichtigungen oder Popups fehlschlagen. Konfigurieren Sie Ihre Tests so, dass sie mit dieser Art von Ereignis umgehen können. In Ranorex Studio ist ein sogenannter Automation Helper verfügbar, mit dem die Bewältigung von Benachrichtigungen und Popups einfach zu konfigurieren ist.

Das Automatisieren eines Workflows bringt verschiedene Herausforderungen mit sich. Typischerweise besteht ein Workflow-Test aus einer Serie von Test Cases, die jeweils einen Schritt im Workflow abdecken. Schlägt ein Schritt fehl, können auch alle weiteren nicht ausgeführt werden. Zusätzlich müssen die einzelnen Schritte nacheinander ablaufen, weswegen sie nicht auf verschiedene Endpunkte aufgeteilt und parallel zueinander ausgeführt werden können. Eine weitere Herausforderung ist, dass bei der Workflow-Automatisierung ein bestimmter Weg durch die Anwendung gewählt werden muss. Dadurch können Bugs übersehen werden, die nur dann auftreten, wenn ein Nutzer einen anderen Weg wählt. Um diese Probleme zu vermeiden, ist es wichtig, Test Cases so modular und unabhängig voneinander wie möglich aufzubauen und den Workflow mit einem keywordgetriebenen Testframework zu managen.

Manche Aspekte von Webanwendungen stellen bei der Testautomatisierung besondere Herausforderungen dar. Eines der Hauptprobleme ist die Erkennung von UI-Elementen mit dynamischen IDs. Ranorex erlaubt die Konfiguration von sogenannten Weight Rules, also Gewichtungen, um den RanoreXPath an dynamische UI-Elemente anzupassen und auch diese robust zu erkennen. Andere Herausforderungen sind zum Beispiel das Wechseln zwischen verschiedenen Fenstern und die Automatisierung von iframes – besonders bei Cross-Domain-Inhalten. Mit Ranorex Studio lassen sich auch Objekte in Cross-Domain-iframes erkennen und automatisieren, sogar wenn die zugehörigen Sicherheitseinstellungen aktiv sind.

Mobile Apps zu automatisieren kann ebenfalls herausfordernd sein. Zum Beispiel müssen diese Apps mit plötzlichen Unterbrechungen umgehen können, da jederzeit ein Anruf eintreffen kann oder bei wenig Akku eine entsprechende Benachrichtigung erscheint. Ebenso müssen Tests verschiedene Geräte abdecken, was besonders bei Android Apps eine Herausforderung darstellt, da die Installationsbasis hier große Varianz bezüglich Bildschirmgröße, Auflösung und Version des Betriebssystems aufweist. Schließlich unterscheiden sich iOS und Android natürlich nicht unwesentlich. Deshalb müssen Tests, die auf einem System funktionieren, meist adaptiert werden, um auch auf dem anderen zu laufen. Wie bei anderen schwierig zu automatisierenden Tests ist es also auch bei Mobile Apps essentiell, ein Testframework zu nutzen, das alle für Ihre App relevanten Technologien unterstützt.

Oft dauert es länger, einen einmalig durchgeführten Test zu automatisieren als ihn einfach manuell auszuführen. Bedenken Sie, dass datengetriebene Tests oder solche, die später zu einem Regressionstest werden, nicht zu dieser Kategorie zählen.

Automatisieren Sie Tests, die objektiv nachvollziehbare, messbare Ergebnisse produzieren. Ein Login-Prozess ist ein gutes Beispiel für so einen Test, da hier klar ist, was passieren soll, wenn gültige bzw. ungültige Daten eingegeben werden. Wenn Ihr Test keine objektiven Erfolgskriterien hat, ist es besser, ihn manuell auszuführen.

Manche Features sind so konzipiert, dass sie sich nicht automatisieren lassen, wie zum Beispiel CAPTCHAs in Webforen. Statt also Zeit auf die Automatisierung von CAPTCHAs zu verschwenden, ist es besser, sie beispielsweise in der Testumgebung zu deaktivieren oder für Testzwecke Code einzufügen, der es erlaubt, sie zu umgehen. Sollte das nicht möglich sein, können CAPTCHAs auch manuell von einem Tester gelöst werden, woraufhin der Rest des Tests wieder automatisiert abläuft. Dazu muss der Test nur so konfiguriert werden, dass er pausiert, bis der Tester ein CAPTCHA gelöst hat, und dann weiterläuft, wenn zum Beispiel ein erfolgreicher Login gemeldet worden ist.

Instabile Features sollten immer manuell getestet werden. Es ist erst dann sinnvoll, Zeit in die Automatisierung zu investieren, wenn das Feature in der Entwicklung einen stabilen Zustand erreicht hat.

Speziell auf Apple iOS sind uninstrumentierte, native Systemapps aufgrund von Sicherheitsmechanismen schwierig bis gar nicht zu automatisieren.