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

Die “Heisenbergsche” Testunschärfe bei automatisierten Testwerkzeugen

Kritische Fehler, die erst im Rahmen des Live-Betriebs öffentlich werden, stellen eine negative Werbung für ein Produkt und die beteiligten Unternehmen dar. Um dies zu verhindern, ist das Thema Testautomatisierung in der modernen Softwareentwicklung ein grundlegender und integraler Bestandteil. Durch die technische Umsetzung mit Testautomatisierungswerkzeugen entstehen aber Probleme, denen wir uns bewusst sein müssen.

Nur durch eine hohe Testabdeckung und der zeitnahen Rückmeldung von Ergebnissen lässt sich die Qualität und Reife des Produktes ausreichend genau nachweisen und bestätigen. Dabei werden von den Beteiligten verschiedene Testvorgehen und Testarten eingesetzt, wie automatisierte Codeanalyse oder automatisierte Unittests durch die Entwickler sowie automatisierte Oberflächentests durch die Tester. Für die unterschiedlichen Testarten wurde bereits früh versucht, übergreifende Kategorien zu finden, wie zum Beispiel die Abgrenzung in Black-Box- und White-Box-Tests.

Laut dem German Testing Board (Archivversion 2.1 des ISTQB® GTB Glossary) versteht man unter Black-Box-Testen “funktionales oder nicht-funktionales Testen ohne Nutzung von Informationen über Interna eines Systems oder einer Komponente” und unter White-Box-Testen einen „Test, der auf der Analyse der internen Struktur einer Komponente oder eines Systems basiert“. Bis vor ein paar Jahren ließen sich Black- und Whitebox-Testverfahren fast synonym zu zwei anderen Einteilungen benutzen: dem dynamischen Test, der „Prüfung des Testobjekts durch Ausführung auf einem Rechner“, und dem statischer Test, dem „Testen von Software-Entwicklungsartefakten, z.B. Anforderungen oder Quelltext, ohne diese auszuführen, z.B. durch Reviews oder statische Analyse“. Heute lässt sich diese Unterscheidung nicht mehr treffen, da Unit-Tests oder Testvorgehen wie Test-Driven-Development (TDD) die eigentliche Abgrenzung zwischen White- und Blackboxtests aufgelöst haben. Ich bezeichne den neuen Bereich als “Grey-Box-Test”. Die Grey-Box-Tests versuchen, erwünschte Vorteile von Black-Box-Tests (spezifikationsgetrieben) und White-Box-Tests (entwicklergetrieben) weitestgehend miteinander zu verbinden und gleichzeitig die unerwünschten Nachteile möglichst zu eliminieren.

Der Vorteil ist, dass Teilkomponenten und Gesamtsysteme mit dem geringen organisatorischen Aufwand der White-Box-Tests geprüft werden können, ohne eventuell “um Fehler herum” zu testen. So werden bei TDD die Komponententests anhand der Spezifikation vor der eigentlichen Entwicklung des Codes erstellt. Die Entwicklung der Komponenten wird erst abgeschlossen, wenn alle Prüfroutinen erfolgreich durchlaufen wurden. Neben den Vorteilen gibt es aber auch ein paar wichtige Aspekte zu beachten. TDD bzw. die Grey-Box-Tests erfordern eine hohe Disziplin, damit diese praktikabel und erfolgreich eingesetzt werden können. Aber viel wichtiger ist der Punkt, dass Grey-Box-Tests nicht unbedacht als vollwertiger Ersatz für Black-Box-Tests gesehen werden sollten.

Warum sollte man sich nicht nur auf automatisierte Grey-Box-Tests verlassen?

Grey-Box-Tests verändern und beeinflussen das System, das sie prüfen sollen. Dieser Aspekt ergibt sich aus der Natur des Tests. Denn was ist ein Test eigentlich? Er ist im Grunde ein empirischer Beweis. Wir stellen eine Hypothese auf und überprüfen diese in einem Experiment. Und in Analogie zu physikalischen Experimenten gilt auch für Softwaretests, dass je mehr ich mich dem Testobjekt nähere, das Ergebnis des Tests dadurch beeinflusst werden kann. Black-Box-Tests werden auf eigenen Testumgebungen durchgeführt, die einen ähnlichen Aufbau wie die Produktionsumgebung aufweisen sollten. Trotzdem bleibt es „ein Versuchsaufbau“. Es werden Mocks für fehlende Komponenten eingesetzt und der Log-Level erhöht, um mehr Informationen zu erhalten.

Grey-Box-Tests, also codenahe Tests, bei denen die zu testende Software ganz oder teilweise ausgeführt wird, sind nicht nur sehr nahe am Testobjekt. Mit Werkzeugen wie JUnit oder TestFX erweitern wir die Codebasis um neue Bestandteile. Es werden neue Zeilen Testcode geschrieben und Testframeworks als Library in die Softwarelösung eingebunden.

Aber auch bei Softwarelösungen wie QF-Test, Expecco oder Squish, die automatisierte Oberflächentests durchführen, rücken wir sehr nahe an das zu testende Objekt heran. Bei älteren Versionen der Automatisierungstools für graphische Oberflächen wurden die Aufnahme der Informationen dadurch erreicht, dass die Positionsdaten des GUI-Elements, wie zum Beispiel eines Buttons, gespeichert und zur Ausführungszeit ein entsprechendes Event abgesetzt wird. Anschließend erstellt die Software ein Screenshot und vergleicht jenes mit einem zuvor erstellten, um die Testergebnisse zu verifizieren. Also weitestgehend ungefährlich. Moderne Tools hingegen verfolgen einen anderen Weg. Sie verbinden sich über eine eigene „Engine“ mit der zu testende Applikation. Dadurch sind Sie in der Lage alle Control-Elemente der Oberfläche zu erfassen, deren Eigenschaften auszulesen und diese auch fernzusteuern. Die zugehörigen Daten werden als ein Modell der Applikation in so genannten GUI Maps abgelegt und sind die Grundlage für die anschließende Erstellung von Testskripten.

Die Auswirkung dieser Nähe zur zu testenden Software kann sein, dass bestimmte Fehlerwirkungen erst dadurch erzeugt oder, noch schlimmer, dadurch verschleiert werden bzw. nicht auftreten. Wir ändern die Grundlage des Tests durch den „komplizierten“ Testaufbau und können uns nicht sicher sein, dass die zu testende Software wirklich so reagiert hätte, wenn wir „nur“ manuell geprüft hätten.

Darum ist es wichtig, das Werkzeug und dessen Besonderheiten zu kennen sowie ein Bewusstsein für mögliche Fehlermaskierung durch die Codenähe der Tests zu haben. Wenn wir darin ein Risiko erkennen, sollten wir unsere automatisierten Tests durch andere manuelle Testarten ergänzen.