10 Best Practices: #1 Was soll man automatisieren?

Willkommen zum ersten Artikel in der Reihe Die 10 Best Practices der Testautomatisierung. Da jeder Tester mit begrenzten Ressourcen arbeitet, muss eine der ersten Überlegungen am Anfang eines jeden Testprojektes sich immer darum drehen, worauf man sich beim Testen überhaupt konzentriert. Mit anderen Worten: In welchen Test Cases sind Zeit und Arbeit am sinnvollsten investiert? In diesem Artikel widmen wir uns genau dieser Frage. Dazu unterteilen wir Tests in drei Kategorien: jene, die man automatisieren sollte; jene, die schwierig zu automatisieren sind und jene, die nicht automatisiert werden sollten.

Tests, die man automatisieren sollte

Im Prinzip lässt sich jeder Softwaretest automatisieren. Man sollte sich aber immer fragen, ob es nicht günstiger ist, einen Test manuell durchzuführen, anstatt ihn aufwändig zu automatisieren und entsprechend zu warten. Dieser Aufwand sollte in erster Linie für jene Tests betrieben werden, die ein Maximum an Rentabilität versprechen. Im Normalfall fallen diese unter eine oder mehrere der folgenden Kategorien:

Tests für stabile Features

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.

Regressionstests

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.

Risikofeatures

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.

Smoke Tests

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.

Datengetriebene Tests

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

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.

Cross-Browser-Tests

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.

Cross-Device-Tests

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.

Tests, die schwierig zu automatisieren sind

Das Automatisieren der folgenden Testarten stellt häufig eine Herausforderung dar. Das heißt allerdings nicht, dass sie nicht automatisiert werden sollten. Es muss aber mit höheren Kosten bei der Erstellung und Wartung gerechnet werden. Prinzipiell hängt die Schwierigkeit der Automatisierung stark von der Technologie der zu testenden Anwendung ab. Wenn Sie ein Automatisierungstool evaluieren oder einen Proof of Concept durchführen, sollten sie deshalb überprüfen, ob und wie ein Tool Ihnen beim Meistern herausfordernder Automatisierungsszenarien helfen kann.

Testen von Technologie-Kombinationen

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.

Dynamische Inhalte

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.

Umgang mit Wartezeiten

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.

Benachrichtigungen/Popups

Ä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.

Komplexe Workflows

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.

Bestimmte Aspekte von Webanwendungen

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.

Bestimmte Aspekte von Mobile Apps

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.

Tests, die nicht automatisiert werden sollten

Manche Arten von Tests können oder sollten nicht automatisiert werden. Das schließt solche Tests ein, die für die erste Automatisierung mehr Zeit und Arbeit beanspruchen, als sie später potentiell einsparen würden. Solche Tests sollten immer manuell ausgeführt werden.

Einmalige Tests

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.

Tests mit unvorhersehbaren Ergebnissen

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.

Features, die sich nicht automatisieren lassen

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

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.

Native OS-Features auf Mobilgeräten

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

Fazit

Konzentrieren Sie sich in Ihrer Automatisierungsstrategie auf die richtigen Test Cases. Das ist der erste Schritt zur Erreichung Ihrer Ziele mit Testautomatisierung. Planen Sie auch Zeit für UX-/Usability-Tests ein. Es liegt in der Natur dieser Tests, dass sie nicht automatisiert werden können und sollten. Nutzen Sie auch unseren Test Case ROI Calculator. Er kann Ihnen bei der Entscheidung helfen, ob ein bestimmter Test Case automatisiert werden sollte. Dazu vergleicht er einfach geschätzte Zeit und Kosten für die Automatisierung mit Zeit und Kosten für die manuelle Ausführung desselben Test Cases. Nicht gedacht ist er zur Bestimmung des ROI eines ganzen Automatisierungsprojekts.

Kostenlose Testversion herunterladen