Kriterienkatalog für die bestmögliche Wahl von Testautomatisierungswerkzeugen

Im ersten Teil der Blogserie haben wir die Herausforderungen bei der Wahl des geeigneten Werkzeugs für die Testautomatisierung skizziert. Im zweiten Teil ging es um die Relevanz und eine mögliche Klassifizierung von Auswahlkriterien der Werkzeuge, die sich zum Teil standardisieren lassen, aber fallweise auch variabel sein müssen. In diesem dritten Artikel stellen wir die Liste der Kriterien, den Kriterienkatalog, dessen Verprobung und die Ergebnisse daraus vor.  

Symbolbild: aufgeschlagenes Buch
Designed by Freepik

Liste der Kriterien

Die folgende Abbildung stellt die finale Liste der Auswahlkriterien dar.  Dabei wurden die variablen Kriterien als „SuT-Kriterien“ gekennzeichnet. Die ermittelten Kriterien können angepasst, erweitert und aktualisiert werden.

Tabellarische Darstellung der Kriterien
Abbildung 1: Liste der Kriterien

Die Standardkriterien sind in vierzehn (14) Oberkriterien unterteilt, wie z.B. in Kompatibilität, Bedienbarkeit, Performance oder Dokumentation. Den Oberkriterien sind Unterkriterien zugeordnet. So hat das Oberkriterium Dokumentation beispielweise drei (3) Unterkriterien.

Kriterienkatalog

Nachdem die Kriterien feststanden, erstellten wir im nächsten Schritt den eigentlichen Kriterienkatalog. Da verschiedene, mehrdimensionale Ziele in die Entscheidungen einfließen, eignete sich dafür ein systematischer Ansatz. Er lässt eine multi-kriteriale Entscheidungsanalyse (auch Multi Criteria Decision Analysis oder MCDA genannt) zu. Eine dieser Anwendungsformen der multi-kriterialen Entscheidungsanalyse ist die sogenannte Nutzwertanalyse (Gansen 2020, S. 5). Die Nutzwertanalyse findet überall dort Anwendung, wo eine Bewertung vorgenommen oder eine Beurteilung getroffen wird, z. B. im Projektmanagement, im Controlling.

Tabellarische Darstellung der Nutzwertanalyse
Abbildung 2: Beispieltabelle Nutzwertanalyse

Anforderungen an den Kriterienkatalog

Für die eigentliche Anfertigung des Kriterienkatalogs definierten wir zunächst die Anforderungen. Sie sind im Folgenden tabellarisch in Form von User Stories zusammengefasst und stellen alle notwendigen Arbeitsschritte dar.

Nr.User Stories
1Als Benutzer möchte ich die Projektstammdaten eingeben, damit ich besser nachvollziehen kann, von wem, wann und für welches Projekt der Katalog erstellt wurde.
2Als Benutzer möchte ich einen neuen Katalog erstellen, um eine neue Nutzwertanalyse durchführen zu können.
3Als Benutzer möchte ich eine Nutzwertanalyse durchführen, um eine objektive Entscheidung treffen zu können
4Als Benutzer möchte ich die Kriterien gerecht und leicht gewichten, um die Relevanz für das Projekt besser steuern zu können.
5Als Benutzer möchte ich einen Überblick über die Bewertungsgrundlage haben, um die Lösungsalternativen besser bewerten zu können.
6Als Benutzer möchte ich einen klaren Überblick über die durchgeführte Nutzwertanalyse haben, damit ich schnell das Werkzeug mit dem höchsten Nutzen finden kann.
7Als Benutzer möchte ich die zuletzt bearbeitete Nutzwertanalyse aufrufen, um sie weiter bearbeiten zu können.
8Als Benutzer möchte ich den Katalog exportieren, damit ich diesen weiterleiten kann.
Tabelle 1: Anforderungen an den Kriterienkatalog

Aufbau des Kriterienkatalogs

Der Kriterienkatalog wurde mit Excel, sowie Visual Basic for Applications (VBA) entwickelt. Das entwickelte Tool wurde in verschiedene Arbeitsmappen unterteilt, die jeweils eine spezifische Aufgabe widerspiegeln.

Die Einstiegsmaske

Beim Öffnen der Datei erscheint ein Dialogfenster (siehe Abbildung 3). Zunächst ist auszuwählen, ob der zuletzt bearbeitete Katalog aufgerufen oder ein neuer Katalog erstellt werden soll. Im Falle eines neuen Katalogs wird dann ein Formular angezeigt, das vom Benutzer ausgefüllt werden muss. Die Eingaben des Benutzers zu den SuT-Kriterien werden dem Katalog als variable Kriterien hinzugefügt (siehe Abbildung 4).

Abbildung einer Maske mit verschiedenen Drop-Down-Feldern
Abbildung 3: Einstiegsmaske des Kriterienkatalogs

Abbildung 4: Angaben der SuT-Kriterien im Katalog

Die Nutzwertanalyse

Die Nutzwertanalyse wird in vier Schritten durchgeführt. Nach der Identifizierung der Kriterien folgt deren Gewichtung. Danach wird die Kriterienerfüllung gemessen und schließlich der Nutzwert jeder Alternative berechnet (Gansen 2020, S. 6). Sind die Bewertungskriterien sachgerecht beurteilt, kann mit Hilfe der Nutzwertanalyse eine objektive, rationale Entscheidung getroffen werden (Kühnapfel 2014, S. 4).

Gewichtung der Kriterien

Nachdem die Kriterien, insbesondere die variablen Kriterien, ausgearbeitet worden sind, ist eine Gewichtung dieser Kriterien vorzunehmen. Entscheidend ist es, die Kriterien entsprechend ihrer Bedeutung für das spezielle Testautomatisierungsprojekt so zu gewichten, damit sie optimal zur Erreichung der Ziele des Projekts beitragen. Die Summe der Gewichtungen von Standardkriterien und variablen Kriterien soll jeweils 100% ergeben. Bei den Standardkriterien werden zuerst die Oberkriterien mit Hilfe der Paarvergleichsmethode gewichtet, in Form einer Matrix zusammengestellt und paarweise miteinander verglichen (Wartzack 2021, S. 315).

Abbildung 5: Paarweiser Vergleich der Oberkriterien für ein Beispielprojekts

Oberkriterien: Sicherheit, Installationsaufwand, Sprachunterstützung

Anschließend wird die Wichtigkeit jedes Unterkriteriums anhand einer Ordinalskala von null bis zwei bestimmt:

0 = „unwichtig“; 1 = „teilweise wichtig“; 2 = „wichtig“

Die vergebenen Punkte werden addiert und mit der entsprechenden Gewichtung des Oberkriteriums multipliziert. Daraus ergibt sich eine proportionale Gewichtung aller Standardkriterien. Entsprechend wird mit den anderen Ober- bzw. Unterkriterien verfahren. Am Ende beträgt die Summe aller Gewichtungen der Standardkriterien am Ende 100%.

Messung der Kriterienerfüllung

Ausgangspunkt ist die Beantwortung der Frage: „In welchem Maße ist das Kriterium bei der zu bewertenden Testautomatisierungswerkzeugen erfüllt?“. Für den Kriterienerfüllungsgrad wird ein 5-stufiges Modell verwendet, dargestellt in Tabelle 2 (Gansen 2020, S. 17).

0Nicht erfüllt.
1Ist unzureichend / kaum erfüllt.
2Ist teilweise erfüllt.
3Ist in gutem Umfang erfüllt.
4Ist in sehr gutem Umfang erfüllt / vollständig erfüllt.
Tabelle 2: Bewertungsschema der Kriterienerfüllung

Wird die Note 4 vergeben, erfüllt das Tool ein Kriterium vollständig. Im Falle der Nichterfüllung wird die Note 0 vergeben. Auf diese Weise werden die entsprechenden Eigenschaften eines Testautomatisierungswerkzeugs zu einer messbaren Größe.

Aggregation der Bewertungen

Liegt der Erfüllungsgrad jedes Kriteriums vor, kann der Nutzwert berechnet werden. Für den Nutzwert gilt folgende Formel:

N i = Nutzwerte der Alternative i

Gj = Gewichtung des Kriterium j

nij = Teilnutzen der Alternative i in Bezug auf das Kriteriums j

Die Teilnutzen werden aufsummiert. Das Ergebnis stellt den tatsächlichen Wert eines Werkzeugs dar. Anhand der ermittelten Nutzwerte lässt sich schließlich eine Rangfolge der betrachteten Alternativen aufstellen und für die Entscheidungsfindung nutzen (Gansen 2020, S. 6). Es lässt sich die Werkzeuglösung wählen, die alle Anforderungen am besten erfüllt und die den größten Nutzwert aufweist.

Es gibt Kriterien, die sich als notwendig herausstellen. Diese werden als Ausschlusskriterien (K.O.-Kriterien) bezeichnet. Wenn ein Ausschlusskriterium (K.O.-Kriterium) nicht erfüllt ist (0), liegt ein Verstoß vor, der zum sofortigen Ausschluss einer Alternativlösung führt.

Abbildung 6: Bewertung und Auswahl

Navigationsleiste und Export

Die Navigationsleiste gibt dem Benutzer einen Überblick über die Struktur des Katalogs und ermöglicht es, sich mühelose darin zu bewegen.

Screenshot der Navigation
Abbildung 7: Navigationsleiste des Kriterienkatalogs

Der Katalog kann als PDF- oder Excel-Datei exportiert und der Speicherort dafür frei gewählt werden.

Abbildung 8: Ausschnitt der leeren Vorlage des Kriterienkatalogs

Ergebnisse der Verprobung des Kriterienkatalogs

Aus der Verprobung konnten folgende relevante Erkenntnisse gewonnen werden:

  • Das Zielmodell zur Identifizierung der variablen Kriterien war hilfreich, um gemeinsam Ideen für die SuT-Kriterien zu sammeln.
  • Die Anwendung des paarweisen Vergleichs schaffte Klarheit über die wichtigen Faktoren bzw. Oberkriterien. Dank der Darstellung wurde die Vergleichbarkeit hergestellt. So konnten „Bauchentscheidungen“ deutlich reduziert werden.
  • Der Kriterienkatalog zeigte einen systematischen, verständlichen und nachvollziehbaren Weg auf, um sich ein geeignetes Werkzeug empfehlen zu lassen. Außerdem konnte festgestellt werden, wo die Stärken des empfohlenen Testautomatisierungsframeworks liegen. So wurde die Abdeckung der Auswahlkriterien mit höherer Relevanz durch das Framework überprüft. Das verringert den Bedarf an Diskussionen innerhalb des Teams, die die endgültige Entscheidung herauszögern würden.
  • Aufgrund des für die Bewertung verwendeten 5-Stufen-Modells war ein sehr detailliertes Know-how über Testautomatisierungswerkzeuge erforderlich, das in den meisten Fällen nicht vorhanden ist. Daher würden die Mitarbeiterinnen und Mitarbeiter einige Kriterien nach ihrem Empfinden bzw. Gefühl bewerten. Folglich wären die Bewertungen teilweise subjektiv und die gewählte Alternative letztlich nicht die optimale. Um in diesem Fall ein zuverlässigeres Ergebnis zu erhalten, sollte mindestens eine weitere Person mit Testexpertise zu der Bewertung hinzugezogen werden.

Fazit & Ausblick

In der vorliegenden Arbeit wurde ein strukturierter und systematischer Ansatz für den Auswahlprozess untersucht. Anhand dessen kann ein geeignetes GUI-Testautomatisierungswerkzeug ausgewählt werden, das sowohl den Projekt- als auch den Unternehmensanforderungen genügt. Dabei wurde ein entsprechender Kriterienkatalog entwickelt, der vor allem als Basis für die Transparenz und Nachvollziehbarkeit der Entscheidungsfindung dient.

Es ist geplant, den Kriterienkatalog in weiteren Projekten einzusetzen. Die dabei gesammelten Erfahrungen sollen in die nächste Version 2.0 des Kriterienkatalogs einfließen.

Dieser Beitrag wurde fachlich unterstützt von:

Kay Grebenstein

Kay Grebenstein arbeitet als Tester und agiler QA-Coach für die ZEISS Digital Innovation, Dresden. Er hat in den letzten Jahren in Projekten unterschiedlicher fachlicher Domänen (Telekommunikation, Industrie, Versandhandel, Energie, …) Qualität gesichert und Software getestet. Seine Erfahrungen teilt er auf Konferenzen, Meetups und in Veröffentlichungen unterschiedlicher Art.

Alle Beiträge des Autors anzeigen

Automatisiertes Layout-Testing von Websites mit Galen

Die Implementierung von Tests in Softwareprojekten ist ein wichtiger Bestandteil des Entwicklungsprozesses. Dank ihrer Eigenschaften lassen sie sich parallelisiert und auf immer gleiche Weise ausführen, ohne zusätzliche Aufwände zu verursachen. Dies erlaubt es, eine schnelle und kosteneffektive Aussage zur Qualität des Softwaresystems zu treffen, wodurch sich eine generell höhere Qualität des gesamten Softwaresystems ergibt.

Auch auf der visuellen Ebene sind Tests wichtig. So gibt es auf Kundenseite meist klare Anforderungen und Vorgaben an das Layout einer Anwendung oder Website sowie auch an deren Unterstützung für verschiedene Endgeräte, Browser und Auflösungen. Diese Anforderungen zu testen, ist manuell ein enormer Aufwand und auch die teilautomatisierte Umsetzung gestaltet sich meist schwierig, da die aufgenommenen Screenshots der Anwendung für die verschiedenen Geräte, Browser und Auflösungen manuell verglichen werden müssen.

Das Galen-Framework soll diese Lücke schließen, indem es dem Anwender erlaubt, seine Testanforderungen in eigenem Programmcode zu formulieren und so eine vollautomatisierte Testabdeckung für das Layout einer Anwendung umzusetzen.

Das Galen-Framework

Galen ist ein Framework zum automatisierten Testen des Layouts einer Website. Durch seine Kompatibilität zu Selenium Grid, lässt es sich in verschiedene Testlandschaften wie z. B. BrowserStack integrieren. Werden also mit BrowserStack verschiedene Tests zu unterschiedlichen Browsern, Devices und Auflösungen durchgeführt, können die Layout-Tests mit Galen parallel dazu durchlaufen werden.

Key-Features

Eine Übersicht der Key-Features zu Galen ist nachfolgend dargestellt:

  • Integration in Selenium Grid
    Eine Integration in andere Test-Tools wie BrowserStack oder Sauce Labs ist möglich
  • Responsive Design
    Das Design von Galen berücksichtigt stark die Bedeutung von Responsive Design und soll die Implementierung dieser Tests vereinfachen
  • Eine verständliche Sprache für Nichtanwender, Einsteiger und Profis
    Über die Galen Specs Language lassen sich komplexe Anforderungen an ein Layout stellen, die unterschiedliche Browser-Fenstergrößen einschließen

Human Readable and Advanced Syntax

Basic Syntax

Mit der Galen Specs Language können komplexe Layouts beschrieben werden. Dies betrifft neben angezeigten Controls auch die Definition verschiedener Bildschirmgrößen und Browser. Ein Vorteil der Sprache ist die einfache syntaktische Definition der Testanforderungen und die einfache Lesbarkeit für Menschen, die nicht mit dem Framework und seiner Syntax vertraut sind. » Galen Specs Language Guide

Galen Basic Syntax
Abbildung 1: Basic Syntax (Quelle: galenframework.com)

Fortgeschrittene Techniken

Für fortgeschrittene Anwender gibt es verschiedene Techniken, die bei der Optimierung der Spezifikation helfen können. So bietet das Framework unter anderem umfangreiche Funktionalitäten für die Erstellung visueller Tests wie Bildvergleiche und Farbschemaverifizierung. » Galen Specs Language Guide

Galen Advanced Syntax
Abbildung 2: Advanced Syntax (Quelle: galenframework.com)

Testen für Profis

Geübte Anwender haben außerdem die Möglichkeit, eigene und komplexere Ausdrücke zu formulieren, um so mehrere Testabfragen in einer einzigen Zeile zu formulieren. Auf diese Weise können klare Spezifikationen sowie gut wartbarer und zuverlässiger Testcode geschrieben werden. » Galen Extras

Galen Testcode
Abbildung 3: Test like a Pro (Quelle: galenframework.com)

Testdokumentation

Für die Dokumentation der Testergebnisse stellt das Framework drei Features bereit:

Error Reporting

  • Galen generiert einen HTML Testbericht
  • Dieser beinhaltet alle Testobjekte einer Seite
  • Beispiel

Screenshots

  • Bei fehlerhaften Tests markiert das Framework das betreffende Element
  • Dies vereinfacht die Fehlersuche
  • Beispiel

Image Comparison

  • Für die visuelle Kontrolle erstellt Galen Bildvergleiche
  • Nicht übereinstimmende Bereiche werden markiert
  • Beispiel

Unterstützung der Testdurchführung in verschiedenen Sprachen

Die Implementierung der Tests ermöglicht Galen in drei Sprachen. Die bereits bekannte Basic Syntax sowie mit JavaScript und Java.

Basic Syntax

Die Basic Syntax soll den schnellen, aber trotzdem mächtigen Einstieg ermöglichen. Mit ihr lassen sich relativ einfach verschiedene Browser wie Firefox, Chrome oder der Internet Explorer für die Testausführung auswählen oder auf Selenium Grid umstellen.

Für den Zugriff auf schwieriger zu erreichende Seiten, welche zum Beispiel durch Sicherheitsmechanismen geschützt sind, gibt es die Möglichkeit, eigenes JavaScript auf der Client-Seite zu implementieren. Durch die Implementierungen von eigenem JavaScript auf der Testseite kann die Website für die durchzuführenden Layout-Prüfungen vorbereitet werden. » Galen Test Suite Syntax

Galen Test Execution Basic Syntax
Abbildung 4: Test Execution Basic Syntax (Quelle: galenframework.com)

JavaScript

Durch die Verwendung von JavaScript steht es dem Anwender frei, sein eigenes Test-Framework zu entwickeln und so komplexe Sachverhalte abzubilden. Das Galen Framework bietet dabei die vier folgenden Funktionalitäten zur Implementierung von JavaScript-Tests.
» JavaScript Tests Guide

  • Die Implementierung von Behandlungen vor und nach den Testvorgängen
  • Das Filtern und die Neuordnung von Testsequenzen
  • Die Verwaltung benutzerdefinierter Data Provider
  • Die Parametrisierung von Tests durch Arrays oder Maps
Galen Test Execution JavaScript Tests
Abbildung 5: Test Execution JavaScript Tests (Quelle: galenframework.com)

Java

Die eigentliche Sprache, die Galen zugrunde liegt, ist Java. Aus diesem Grund versteht es sich dann natürlich auch, dass für Java eine API zur Verfügung steht und dass die Java Virtual Machine zur Ausführung der Tests installiert sein muss. Die Java-API kann über das Central Maven Repository in Maven-Projekte eingebunden werden. » Git Beispielprojekt

Galen Test Execution Java API
Abbildung 6: Test Execution Java API (Quelle: galenframework.com)

Fazit

Die Durchführung von Layout-Tests ist eine aufwendige Aufgabe, die mit zunehmender Anzahl an Tests viele Ressourcen in Softwareprojekten kosten kann. Mit dem Galen Framework existiert eine Lösung der automatischen Durchführung und Dokumentation von Layout-Tests, die zudem eine komfortable Integration in bestehende seleniumbasierte und andere Teststrategien bietet. Durch ihre einfache und menschenlesbare Syntax ist sie für nahezu alle Projektteilnehmer verständlich und unterstützt somit die rollenübergreifende Zusammenarbeit im Softwareprojekt.

Kochrezepte für Testautomatisierung (Teil 1) – Suppe

Zutaten, Küchengeräte und wer ist der Koch?

Ein Kollege sprach mich kürzlich an und fragte, ob ich ein Rezept für eine gute Testautomatisierung kenne. Ich sagte, dass man dafür – wie für eine gute Suppe – nicht nur ein Rezept braucht, sondern es kommt auf die Ausstattung der Küche, die Zutaten und den Koch an. Entscheidend für die Testautomatisierung sind also die Projektrahmenbedingungen, die Auswahl der Testwerkzeuge und die Tester die an der Testautomatisierung beteiligt sind.

Wie können wir feststellen, ob die Rahmenbedingungen (nicht verwechseln mit Ramenbedingungen) für die Testautomatisierung gegeben sind? Grundlegend ist hierbei zu unterscheiden, ob sich das Software-Projekt noch in der Vorplanung befindet und die Testautomatisierung von Anfang an eingeplant wird oder ob es sich um ein Projekt handelt, welches bereits läuft und mit Testautomatisierung unterstützt werden soll.

Eines schon vorweg gesagt – je früher mit einer gut geplanten Testautomatisierung begonnen wird, desto wahrscheinlicher wird es eine erfolgreiche Testautomatisierung. Die Gründe liegen oft darin, dass die anfänglichen Aufwände der Testautomatisierung unterschätzt werden und sich der Nutzen rein rechnerisch erst nach Projektende einstellt.

Um dem zu begegnen ist für ein beginnendes Projekt eine gute Planung und für ein laufendes Projekt erst einmal eine Vorstudie der laufenden Prozesse, Testfälle und Rahmenbedingungen notwendig. In so einer Vorstudie sind unter anderem das bereits vorhandene Testfallportfolio, das Testobjekt und die Kenntnisse der Tester zu analysieren und zu bewerten. Auf diese Weise können wir erkennen, wo die eigentlichen Schwachpunkte des Projektes im Testbereich liegen.

Oft wird versucht mit Testautomatisierung Probleme zu lösen, die nichts mit der Testautomatisierung zu tun haben bzw. gegebenenfalls dadurch noch verschlimmert werden. Das ist wie beim Kochen, wenn die Suppe nicht schmeckt wird diese nicht zwingend besser, wenn wir einfach den Koch durch einen Automaten austauschen. Oft wird das Ergebnis sogar schlechter, wenn ich den Kaffeeautomaten im Flur betrachte. Wichtig ist, dass die Voraussetzungen für die Testautomatisierung eine Mindestqualität erreicht haben, bevor mit der Toolauswahl oder gar der Automatisierung begonnen werden kann. Die Testautomatisierung ist der Sahneklecks auf der Suppe, d. h. Testautomatisierung ist nur in einem gut funktionierenden Testprozess erfolgreich. Auch die Testfälle müssen eine ausreichende Detailtiefe zur Automatisierung haben. Die benötigte Detailtiefe ist davon abhängig in wie weit der Tester die nötigen fachlichen Kenntnisse zum Testobjekt mitbringt. Hier könnte der eine oder andere auf die Idee kommen gleich die Fachseite – also die die das Fachwissen haben – die Testautomatisierung machen zu lassen. Das ist meist keine gute Idee, da den Mitarbeitern die Zeit fehlt. Zum einen steht ihre tägliche Arbeit in der Priorität immer höher als die Testautomatisierung und zum anderen müssen die Toolkenntnisse und Testerfahrungen erst aufgebaut werden. Daher empfiehlt es sich, dass die Fachseite die manuellen Testfälle in einer ausreichenden Detailtiefe liefert, welche der Tester auch ohne Domainwissen versteht. Anschließend nimmt der Tester mit seiner Testerfahrung und der nötigen Toolkenntnis die Automatisierung vor.

Es ist illusorisch alles automatisieren zu können, darum wird in der Vorstudie ein Priorisierung der Testfälle vorgenommen. Dabei ist auch das Testobjekt bzw. die zu testende Software auf Automatisierbarkeit zu prüfen. Besonders problematisch für die Testautomatisierung sind z. B. dynamische Objekt-IDs, die sich bei jedem erneuten Aufruf ändern.

Wie wir auch aus der Küche bereits kennen, ist dann auch noch der Koch wichtig, d. h. der Tester, der die Testautomatisierung durchführt. Zum einen benötigt dieser das nötige Toolwissen und zum anderen muss er auch entscheiden können, wo sich die Testautomatisierung im Einzelnen lohnt. Zum Beispiel macht es keinen Sinn eine Funktion in der Software zu automatisieren, die nur extrem selten benötigt wird und im Automatisierungsaufwand sehr hoch ist.

Darum sollte man sich immer an das Rezept halten:

  • mit gutem Augenmaß und einem Gespür für den Aufwand eine ausgewogene Komposition – Kosten und Nutzen im Auge behalten
  • nicht nur auf die Technik verlassen – auch das eigene Handwerk ist wichtig
  • Testautomatisierung funktioniert nur, wenn vorher die grundlegenden Testaufgaben und Prozesse funktionieren – erst Zwiebeln schneiden lernen und dann mit der Bouillabaisse anfangen

Eine weitere Herausforderung für die Testautomatisierung sind die Testdaten. Hierzu aber mehr in meinem nächsten Blogbeitrag. Bis dahin wünsch ich schon mal ein Frohes Fest und überlasst die Weihnachtsgans nicht achtlos einem Automaten.