Suche
Kolumne

Warum alle UI Testing hassen… und warum der schlechte Ruf (teilweise) nicht verdient ist!

Alexandra Schladebeck

(c) Shutterstock / Aquir

 

Willkommen zur ersten Ausgabe unserer neuen Kolumne über Qualitätssicherung und Testing! Die Test Consultants der BREDEX GmbH werden in regelmäßigen Abständen ihre Erfahrungen sowie Tipps & Tricks für das Testen und die Testautomatisierung teilen. Den Anfang macht Alexandra Schladebeck mit dem Thema UI Testing.

Warum alle UI Testing hassen…

In dieser ersten Kolumne geht es mir um mein ganz persönliches Steckenpferd: die Probleme, unter denen viele Projekte in der UI-Testautomatisierung leiden, und wie viele dieser Probleme vermieden werden könnten.

UI-Testautomatisierung als wichtiger Bestandteil eines Projektes

Schaut man sich die bekannte Testautomatisierungspyramide an, wird die UI-Testautomatisierung als kleinste Einheit dargestellt:

Genäß dieser Darstellung ergibt es durchaus Sinn, die richtigen Tests entsprechend der passenden Ebene zu automatisieren (mehr dazu später) und schnell laufende (Unit-)Tests für zahlreiche Überprüfungen auszunutzen. Dennoch sind automatisierte UI-Tests weiterhin Teil der Pyramide und sollten daher auch beachtet werden.

Je nachdem, wie eine Applikation aufgebaut ist, können mehr oder weniger UI-Tests vonnöten sein – in den wenigsten Fällen allerdings werden gar keine benötigt. Schließlich bietet die Benutzeroberfläche die wesentliche Schnittstelle, über die die Nutzer mit dem System interagieren. Die Qualität, wie sie durch den Umgang mit der UI wahrgenommen wird, fällt schnell auf. Kurzgefasst: obwohl UI-Tests mehr Infrastruktur brauchen und langsamer laufen, sind sie für viele Projekte wichtig und sinnvoll.

Das Tool ist nicht die Lösung

Mittlerweile gibt es viele UI-Testautomatisierungstools, die eine gute Reife erreicht haben. Egal mit welchem Tool man UI-Testautomatisierung betreibt, der Fokus der Tools liegt bei genau einem (technischen) Aspekt der Automatisierung: der Lokalisierung und dem Ansprechen der UI-Komponenten. Um auf ihnen Aktionen auszuführen, bietet jedes Tool eine Schnittstelle an. Bei manchen Tools ist diese Schnittstelle relativ groß, mit zahlreichen Aktionen für viele Komponententypen (bspw. Jubula). Andere Tools (bspw. Selenium) haben ein sehr schlankes API, mit dem man eigenständig das Adressieren von komplexeren Komponenten programmieren kann (bzw. muss). Kein Tool schreibt jedoch vor, wie man diese Tests fachlich aufbauen soll.

Gründe für viele Probleme

Genau hier liegt die Herausforderung. Anhand des API kann man einzelne Schritte automatisieren. Der Unterschied zwischen einer Reihe automatisierter Schritte und einem vernünftigen, wartbaren, analysierbaren Testfall ist allerdings groß und bedeutend.

Fehlende Struktur

Es ist sehr einfach, eigene Workflow-Schritte (wir nennen sie in solchen Fällen explizit nicht „Testfall“) anhand dieser technischen APIs direkt zu automatisieren. Dies kann umso schneller mit dem beliebten Capture-Replay-Ansatz passieren. Allerdings geht es auch sehr einfach, wenn man die Tests manuell schreibt.

So ergibt sich die unten abgebildete Teststruktur.

Auch wenn diese Schritte im ersten Moment erfolgreich durchlaufen werden, bringen sie für die spätere Erweiterung und Wartung Probleme mit sich.

  1. Abläufe werden redundant automatisiert. Braucht der nächste Test den gleichen fachlichen oder technischen Ablauf, wird dieser wahrscheinlich neu erzeugt. Bei der Wartung und Erweiterung führt dieser Zustand zu großen Aufwandsproblemen und schwer behebbaren Fehlern im Test (die gleiche oder eine ähnliche Änderung muss an mehreren Stellen durchgeführt werden).
  2. Durch das direkte Aufrufen des technischen API werden viele Stakeholder für die Automatisierung ausgeschlossen: Es fehlen Zwischenebenen, um die Tests hierarchisch von oben (fachlich) nach unten (technisch) oder anders herum zu betrachten. Nur Teammitglieder, die in der Lage sind, die technische Schnittstelle zu verstehen, können so an den Tests mitwirken.

Falscher Einsatz

Das zweite Problem ist das Einsatzgebiet von UI-Tests. Wie oben erwähnt, gibt es verschiedene Testebenen, die in einem Projekt automatisiert testbar sind. Allzu häufig wird ein UI-Testautomatisierungstool für Tests eingesetzt, die auf unteren Ebenen (bspw. Unit-Tests) besser aufgehoben wären.

Auswege

Auf das zweite Problem gehen wir hier nicht tiefer ein. Für die erste erwähnte Problemstellung – dass Tests ganz ohne Zwischenebenen erstellt werden – stellen wir einen Lösungsansatz vor, der auf bekannte Muster aus dem Web-Testing und dem Software-Design basiert.

UI Testing

Wie oben abgebildet, kann ein automatisierter Testfall (eine unabhängig ausführbare Einheit, mit einem klaren Ziel, Vor- und Nachbedingungen sowie Überprüfungen) in verschiedene Ebenen aufgeteilt werden. Diese vertikale Dekomposition dient mehreren Zwecken:

  • der Trennung zwischen Fachlichkeit (was muss der Test machen) und Technik (wie es im Allgemeinen oder in einem bestimmten Fall erfolgt). Dadurch ist es möglich, dass Tester mit einer fachlichen Sichtweise sich um die „höheren“ Ebenen kümmern können, während sich Tester mit technischer Perspektive auf „untere“ Ebenen konzentrieren.
  • der Festlegung der zu bedienenden Komponente an genau einer Stelle (an der fachlich atomaren Aktion), sodass die Pflege eines Object Maps niedrig gehalten wird.
  • der Wiederverwendbarkeit von Modulen und der damit verbundenen Aufwandsreduzierung bei zukünftigen Änderungen.
  • bei programmierten Tests in z.B. Java die Möglichkeit, zwischen public (Abläufe) und private (Aktionen, interne Abläufe) Bausteinen zu unterscheiden.

Neben der vertikalen Aufteilung sollte ebenfalls eine horizontale Dekomposition erfolgen. Die Ebenen „fachlich atomare Aktionen“ sowie „fachliche Abläufe“ werden zusätzlich in Anwendungsbereiche aufgeteilt. Wer das Page Object Pattern kennt, kennt diese Bereiche als „Pages“. In unserer Sprache nennen wir sie „Kontexte“, denn ein fachlicher Kontext kann sich (je nach Fachlichkeit) über mehrere Seiten oder Masken erstrecken.

UI Testing

Diese Aufteilung bietet folgende Vorteile:

  • Sucht ein Tester nach einem Baustein für einen bestimmten fachlichen Bereich, weiß er, wo sich dieser befindet. Ist der Baustein nicht bereits im Kontext vorhanden, kann dieser hinzugefügt werden. Durch das einfache (Wieder)finden schon automatisierter Bausteine werden Redundanzen reduziert.
  • Die Aufteilung der Aufgaben im Team kann anhand der fachlichen Kontextstruktur stattfinden – Tester A arbeitet in Kontext A usw.

Die oben dargestellten Konzepte sollten vielen Entwicklern bekannt sein. Wir reden über Single Level of Abstraction, Kapselung und Kohäsion. Nur weil die Konzepte bekannt sind, heißt das jedoch nicht, dass sie im Bereich der UI-Automatisierung erfolgreich oder korrekt eingesetzt werden. Aus der technischen Perspektive ist die Versuchung groß, einfach auf der technische Ebene zu bleiben. Werden fachliche Tester ohne eine geeignete Ausbildung für die UI-Testautomatisierung eingesetzt, entstehen ggf. gegensätzliche Aufteilungen. Egal ob Tester oder Entwickler – jedes Teammitglied sollte ein Auge auf eine geeignete Strukturierung automatisierter UI-Tests haben und dieses Wissen stetig erweitern.

Ausblick

Die hier beschriebenen Ebenen sind die Basis für viele nützliche Muster in der Testautomatisierung, worüber wir sicher in folgenden Kolumnen berichten werden. Die Konzepte lassen sich in verschiedenen Programmiersprachen oder Domain Specific Languages umsetzen – und lassen sich sogar automatisiert auf Korrektheit überprüfen. Neben den reduzierten Aufwänden für die Testerweiterung und Testwartung bietet dieser Ansatz eine Möglichkeit, verschiedene Teammitglieder in die UI-Tests einzubinden, um ihre eigene Perspektiven (fachlich oder technisch) zu vertreten sowie die Aufgabe der Testautomatisierung im Team adäquat zu verteilen.

Geschrieben von
Alexandra Schladebeck
Alexandra Schladebeck
Alex Schladebeck ist Leiterin der Software Qualität und Test Consulting bei BREDEX GmbH. Sie verbringt ihre Zeit in Kommunikation mit Kunden, Testern, Benutzern und Entwicklern. Besonders interessiert sich Alex neben Benutzerfreundlichkeit und Ergonomie auch für Agilität in Test- und Entwicklungsprozessen. Sie spricht häufig auf Konferenzen über Agilität und Qualitätssicherung aus Sicht ihrer Projekterfahrung.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.