Wie lassen sich aus Äquivalenzklassen, Grenzwerten und fachlichen Regeln systematisch Testfälle erzeugen, ohne in einer Flut von Kombinationen unterzugehen? Das Open-Source-Werkzeug G.R.E.A.T. unterstützt genau dabei – und schafft gleichzeitig eine Grundlage für datengetriebene Testautomatisierung.

Die Herausforderung: Welche Testfälle brauchen wir wirklich?

Stellen wir uns ein Softwaresystem mit fünf Eingabeparametern vor. Für jeden Parameter haben wir drei Äquivalenzklassen identifiziert. Das klingt zunächst überschaubar. Würden wir jedoch sämtliche Kombinationen testen, ergäben sich bereits 243 Testfälle. Und dabei haben wir noch keine Grenzwerte, keine ungültigen Eingaben und keine fachlichen Abhängigkeiten berücksichtigt. In realen Projekten entstehen schnell viele Hundert oder Tausend theoretisch mögliche Kombinationen. Alle zu testen ist häufig weder wirtschaftlich noch sinnvoll.

Die eigentliche Herausforderung im Testdesign lautet deshalb nicht:

Wie können wir möglichst viele Testfälle erzeugen?

Sondern:

Wie finden wir eine sinnvolle Auswahl von Testfällen, die relevante Risiken, Kombinationen und Fehlerquellen abdeckt?

Genau hier setzt G.R.E.A.T. an.

Was ist G.R.E.A.T.?

G.R.E.A.T. steht für Georgs Radikal Einfacher Automatisierter TestcaseDesigner.

Hinter dem etwas augenzwinkernden Namen steckt ein Open-Source-Werkzeug zur systematischen Erstellung von Testfällen. Die Grundidee ist einfach: Wir definieren die Eingabeparameter unseres Testobjekts, beschreiben passende Äquivalenzklassen, legen fachliche Regeln fest und wählen eine geeignete Strategie zur Testfallkombination. G.R.E.A.T. übernimmt daraufhin einen großen Teil der Kombinationsarbeit. Das Werkzeug stellt die erzeugten Testfälle tabellarisch dar und ermöglicht ihren Export in unterschiedliche Formate.

1. Äquivalenzklassen als Grundlage des Testdesigns

Die Äquivalenzklassenbildung gehört zu den grundlegenden Methoden des Black-Box-Testens. Anstatt jeden möglichen Eingabewert einzeln zu prüfen, fassen wir Werte zusammen, für die wir ein vergleichbares Verhalten des Testobjekts erwarten. Beispielsweise könnte ein Mengenfeld für eine Bestellung folgende Äquivalenzklassen besitzen:

  • Gültige Bestellmengen von 1 bis 99
  • Ungültige Bestellmengen kleiner als 1
  • Ungültige Bestellmengen größer als 99

G.R.E.A.T. ermöglicht es, solche Klassen zu strukturieren und anschließend miteinander zu kombinieren. Dadurch muss nicht jede mögliche Kombination manuell in einer Excel-Tabelle zusammengestellt werden.

2. Testfallkombinatorik: Von Each Choice bis N-wise

Nicht für jedes Testobjekt ist dieselbe Kombinationstiefe sinnvoll. Bei einem einfachen Formular kann es ausreichen, dass jeder relevante Wert wenigstens einmal in einem Testfall vorkommt. Bei komplexeren Geschäftsprozessen möchten wir möglicherweise sämtliche Kombinationen von jeweils zwei oder drei Parametern betrachten. G.R.E.A.T. unterstützt dafür unterschiedliche Strategien.

Each Choice: Jeder definierte Wert beziehungsweise jede Äquivalenzklasse wird nach Möglichkeit mindestens einmal berücksichtigt. Das ist ein guter Einstieg, wenn wir eine überschaubare Grundmenge von Testfällen benötigen.

Pairwise: Hier konzentrieren wir uns auf die paarweise Kombination von Parametern. Ziel ist es, die zulässigen Wertepaarungen systematisch abzudecken, ohne sämtliche Gesamtkombinationen erzeugen zu müssen.

N-wise: Wenn Wechselwirkungen zwischen mehr als zwei Parametern relevant sind, kann eine höhere Kombinationsstärke gewählt werden.

Lineare Expansion und vollständige Kombinationen: Je nach Testziel lassen sich umfangreichere Kombinationen erzeugen.

MC/DC-orientiertes Testdesign: Auch die gezielte Variation einzelner Bedingungen wird unterstützt. Dabei ist wichtig, zwischen generierten Testfallvarianten und einem formalen Nachweis der MC/DC-Abdeckung im ausgeführten Programm zu unterscheiden.

Das Werkzeug nimmt uns die Kombinationsarbeit ab – nicht die Verantwortung, die richtige Teststrategie auszuwählen.

3. Grenzwertanalyse: Weil Fehler häufig an den Grenzen liegen

Viele Fehler entstehen nicht bei typischen Eingaben, sondern unmittelbar an den Grenzen gültiger Wertebereiche. Nehmen wir erneut das Mengenfeld mit einem zulässigen Bereich von 1 bis 99. Interessante Testwerte wären beispielsweise 0, 1, 2, 98, 99 und 100. G.R.E.A.T. unterstützt die Grenzwertanalyse für numerische Eingaben. Dabei können auch mehrere Bereiche definiert und als erlaubt oder unerlaubt gekennzeichnet werden. So lassen sich sowohl positive als auch negative Testfälle aus den beschriebenen Wertebereichen ableiten. Gerade bei komplexeren Wertebereichen hilft diese systematische Vorgehensweise, kritische Grenzen nicht zu übersehen.

4. Fachliche Regeln: Der entscheidende Unterschied zwischen mathematischer und sinnvoller Kombinatorik

Eine mathematisch mögliche Kombination ist nicht automatisch eine fachlich sinnvolle Kombination. Betrachten wir ein Bestellsystem. Kund:innen können möglicherweise zwischen Abholung und Versand wählen. Zusätzlich gibt es eine Option für Expressversand. Die Kombination „Abholung“ und „Expressversand aktiviert“ könnte jedoch fachlich ausgeschlossen sein. Oder eine Bezahlung auf Rechnung ist nur für bestimmte Kundengruppen zulässig. Solche Zusammenhänge sind für ein sinnvolles Testdesign entscheidend. G.R.E.A.T. bietet deshalb ein Regelwerk, mit dem fachliche Abhängigkeiten beschrieben werden können. Dazu gehören beispielsweise:

Sich gegenseitig ausschließende Kombinationen: Zwei bestimmte Äquivalenzklassen dürfen nicht gemeinsam in einem regulären Testfall vorkommen.

Bedingte Abhängigkeiten: Wenn eine bestimmte Äquivalenzklasse gewählt wird, muss eine andere Bedingung erfüllt sein.

Zusammengehörige Werte: Bestimmte Werte können durch Regeln miteinander kombiniert werden.

Diese Regeln können bei der Testfallgenerierung berücksichtigt werden. Dadurch lassen sich fachlich unzulässige Kombinationen aus der regulären Kombinatorik herausfiltern. Hier lohnt sich allerdings eine wichtige Unterscheidung: Ein ungültiger Eingabewert kann ein ausdrücklich gewünschter Negativtest sein. Eine fachlich ausgeschlossene Kombination soll dagegen möglicherweise gar nicht erst in einer regulären Testfallmenge auftauchen.

Die Qualität des Regelwerks beeinflusst deshalb unmittelbar die Qualität der generierten Testfälle.

5. Wiederverwendbare Datenklassen: Nicht immer bei null anfangen

In vielen Projekten begegnen uns dieselben Arten von Testdaten immer wieder. Denken wir beispielsweise an Artikelnummern, Kundennummern, Datumswerte, E-Mail-Adressen oder andere fachliche Eingaben. Es ist wenig sinnvoll, diese Werte in jedem Testprojekt erneut zusammenzustellen. G.R.E.A.T. unterstützt daher die Verwaltung wiederverwendbarer Datenklassen. Neben vordefinierten Datenklassen können eigene Sammlungen fachlicher Testwerte angelegt und wiederverwendet werden. Das kann die Arbeit über mehrere Projekte hinweg vereinfachen und gleichzeitig helfen, bewährte Testdaten nicht zu vergessen.

6. Fehler provozieren: Ungewöhnliche Testdaten mit BugMagnet

Ein guter Testfall prüft nicht nur, ob eine Anwendung mit den erwarteten Eingaben funktioniert. Er hinterfragt auch, was bei ungewöhnlichen oder problematischen Eingaben geschieht. Wie reagiert ein Eingabefeld auf besondere Unicode-Zeichen? Was passiert bei unerwarteten negativen Zahlen? Werden extrem große Zahlen korrekt verarbeitet? Wie verhält sich die Anwendung bei ungewöhnlich langen Postleitzahlen oder fehlerhaften E-Mail-Adressen? Solche Eingaben sind häufig deutlich interessanter als der hundertste Test mit gewöhnlichen Musterdaten. G.R.E.A.T. bietet dafür eine besonders spannende Möglichkeit: den Import von Testdaten aus dem Open-Source-Projekt BugMagnet.

Sammlungen typischer problematischer Eingaben – etwa besondere Zeichenfolgen, ungewöhnliche Zahlenwerte, Grenzwertüberschreitungen oder fehlerhafte Eingabeformate – können in die eigenen Datenklassen und die Testfallgenerierung einfließen. Auf diese Weise unterstützt G.R.E.A.T. nicht nur die systematische Kombination bekannter Äquivalenzklassen, sondern liefert auch Anregungen, das Testobjekt gezielt mit ungewöhnlichen Daten herauszufordern.

7. Von der Testfallgenerierung zur Testautomatisierung

Ein weiterer wichtiger Aspekt ist die Weiterverarbeitung der generierten Testfälle. G.R.E.A.T. stellt die Testfälle nicht nur in einer Tabelle dar, sondern bietet den Export als:

  • JSON
  • CSV
  • Excel (.xlsx)

Gerade JSON und CSV sind für datengetriebene Testautomatisierung interessant. Anstatt Eingabewerte direkt in automatisierten Testskripten fest einzubauen, können diese aus externen Testdatendateien gelesen werden. Damit ergibt sich ein sinnvoller Arbeitsablauf:

Äquivalenzklassen definieren → Fachliche Regeln festlegen → Kombinatorik auswählen → Testfälle generieren → Exportieren → In der Testautomatisierung verwenden.

Die eigentliche Testausführung, die Prüfung des erwarteten Verhaltens und die Auswertung der Ergebnisse bleiben weiterhin Aufgaben des jeweiligen Testprozesses beziehungsweise des eingesetzten Automatisierungsframeworks. G.R.E.A.T. soll keine vorhandenen Testautomatisierungswerkzeuge ersetzen. Vielmehr unterstützt es eine vorgelagerte Aufgabe, die in der Praxis häufig zu kurz kommt: das systematische Entwerfen und Zusammenstellen geeigneter Testfälle. Selbstverständlich eignen sich die erzeugten Tabellen ebenso als Grundlage für manuell durchgeführte Tests.

8. Für wen ist G.R.E.A.T. interessant?

G.R.E.A.T. richtet sich an alle, die sich mit systematischem Softwaretesten beschäftigen. Softwaretester:innen können damit Testfälle aus Äquivalenzklassen und Regeln ableiten. Testmanager:innen können unterschiedliche Kombinationsstrategien vergleichen und die Auswahl von Testfällen nachvollziehbarer gestalten. Für Testautomatisierer:innen entstehen strukturierte Datengrundlagen, die sich in datengetriebene Tests integrieren lassen. Auch für die Ausbildung und Weiterbildung im Softwaretesten ist das Werkzeug interessant. Methoden wie Äquivalenzklassenbildung, Grenzwertanalyse und kombinatorisches Testdesign werden an konkreten Beispielen greifbarer.

9. OpenAPI: Testfalldesign direkt in den Entwicklungsprozess integrieren

Eine besonders interessante Eigenschaft von G.R.E.A.T. steckt unter der Oberfläche.

Die Funktionen des Werkzeugs sind über eine REST-API zugänglich, deren Schnittstellen nach OpenAPI beschrieben und über Swagger dokumentiert sind.

Das bedeutet: G.R.E.A.T. muss nicht zwingend über seine grafische Benutzeroberfläche bedient werden. Andere Anwendungen können die bereitgestellten Funktionen über die API aufrufen. Damit eröffnen sich interessante Möglichkeiten für Teams, die ihre Entwicklungs- und Testprozesse stärker miteinander verbinden möchten.

Testfälle bereits bei der Erstellung von User Stories entwickeln

Stellen wir uns ein Entwicklungsteam vor, das seine Anforderungen in Jira oder einem vergleichbaren Werkzeug verwaltet. Normalerweise entsteht dort zunächst eine User Story mit Akzeptanzkriterien. Die eigentlichen Testfälle werden häufig erst später erstellt – manchmal sogar erst, wenn die Implementierung bereits weit fortgeschritten ist.

Warum also nicht die Testfälle direkt beim Erstellen oder Verfeinern einer User Story mitdenken?

Ein technisch etwas versiertes Team könnte beispielsweise eine eigene Integration entwickeln, die Funktionen von G.R.E.A.T. direkt aus Jira heraus aufruft.

Ein möglicher Ablauf wäre:

  1. Eine neue User Story wird in Jira angelegt.
  2. Die fachlich relevanten Eingabeparameter und Äquivalenzklassen werden definiert.
  3. Fachliche Regeln und Abhängigkeiten werden beschrieben.
  4. Über die OpenAPI-Schnittstelle wird G.R.E.A.T. aufgerufen.
  5. Die generierten Testfallkombinationen werden der User Story zugeordnet oder als Testfalldaten abgelegt.

Die benötigte Integration muss das Team selbst entwickeln. Eine fertige Jira-Anbindung ist damit nicht automatisch vorhanden.

Ein wichtiger Baustein für Test First

Dieser Ansatz unterstützt insbesondere eine Test-First-Denkweise. Wer sich frühzeitig mit Äquivalenzklassen, Grenzwerten und fachlichen Regeln beschäftigt, stellt häufig Fragen, die in der ursprünglichen Anforderung noch gar nicht beantwortet wurden. Was passiert bei einem ungültigen Wert? Welche Kombinationen sind überhaupt erlaubt? Welche fachlichen Sonderfälle wurden übersehen? Welche Ergebnisse werden für die einzelnen Situationen erwartet? Solche Fragen können bereits während der Anforderungsanalyse gestellt und geklärt werden. Die generierten Testfallkombinationen liefern dabei eine Grundlage. Erwartete Ergebnisse und fachliche Bewertungen müssen weiterhin bewusst definiert werden.

G.R.E.A.T. könnte damit direkt dort eingesetzt werden, wo Testqualität beginnt: bei der Beschreibung der Anforderungen.

Und genau das ist eine interessante Perspektive für Teams, die Test First, Shift Left oder eine engere Zusammenarbeit zwischen Entwicklung, Fachbereich und Test verfolgen. Bei einer Integration in andere Werkzeuge sind selbstverständlich auch die Lizenz- und Nutzungsbedingungen des Projekts zu beachten.

10. Was kommt als Nächstes? Ein Blick auf die Weiterentwicklung

G.R.E.A.T. ist kein abgeschlossenes Projekt. Bereits jetzt befinden sich weitere interessante Funktionen in der Entwicklung beziehungsweise Erprobung. Drei Erweiterungen möchte ich besonders hervorheben.

Entscheidungstabellentests: Ursachen und Wirkungen systematisch untersuchen

Die Erstellung von Entscheidungstabellen für das Testdesign ist technisch bereits umgesetzt, befindet sich jedoch noch in der Erprobung und ist noch nicht regulär freigegeben. Die Entscheidungstabellentest-Technik ist besonders interessant, wenn ein System abhängig von mehreren Bedingungen unterschiedliche Ergebnisse liefern muss. Beispielsweise könnte eine Rabattberechnung davon abhängen, ob Kund:innen registriert sind, einen bestimmten Kundenstatus besitzen und einen gültigen Gutschein verwenden. In G.R.E.A.T. sollen solche Zusammenhänge über Ursachen und Wirkungen beschrieben werden können.

Der Ablauf ist dabei folgender:

  1. Die möglichen Ursachen beziehungsweise Bedingungen werden definiert.
  2. Die fachlich relevanten Wirkungen werden erfasst.
  3. Sich gegenseitig ausschließende Ursachen können gekennzeichnet werden.
  4. G.R.E.A.T. generiert daraus die Entscheidungstabelle unter Berücksichtigung dieser Ausschlüsse.
  5. Anschließend ordnet der Tester den einzelnen Kombinationen die fachlich zutreffenden Wirkungen zu.

Gerade der letzte Schritt ist wichtig. Denn ein Werkzeug kann zwar Kombinationen von Bedingungen erzeugen, aber nicht ohne entsprechendes fachliches Wissen entscheiden, welche Wirkung eine bestimmte Kombination haben muss. Diese Zuordnung bleibt bewusst Aufgabe der Testdesigner:innen.

Damit verbindet G.R.E.A.T. die automatisierte Erstellung einer Entscheidungstabelle mit der notwendigen fachlichen Bewertung durch den Menschen.

Authentifizierung und Rollen: G.R.E.A.T. für unterschiedliche Benutzergruppen

Eine weitere Erweiterung befindet sich derzeit in der Entwicklung: Eine Benutzeranmeldung mit Benutzername und Passwort. Damit soll der Zugriff auf G.R.E.A.T. künftig geschützt und über unterschiedliche Benutzerrollen gesteuert werden können. Geplant sind drei Rollen:

  • Administration: Für die Verwaltung und Administration des Systems.
  • Testdesign: Für Anwender:innen, die Testprojekte bearbeiten und Testfälle entwerfen beziehungsweise generieren.
  • Nur Lesen: Für Anwender, die bestehende Projekte und Ergebnisse ansehen, jedoch nicht verändern sollen.

Gerade für den gemeinsamen Einsatz in Teams ist eine solche Unterscheidung sinnvoll. Nicht jeder, der Testfälle einsehen möchte, benötigt automatisch die Berechtigung, Äquivalenzklassen oder fachliche Regeln zu verändern. Die neue Rollenverwaltung soll deshalb helfen, die gemeinsame Nutzung kontrollierter und sicherer zu gestalten.

Einfachere Installation: G.R.E.A.T. auch ohne Python-Erfahrung nutzen

Nicht alle Softwaretester:innen sind gleichzeitig Python-Entwickler:innen. Und das sollte auch keine Voraussetzung dafür sein, ein Werkzeug für systematisches Testfalldesign ausprobieren zu können. Deshalb ist zusätzlich ein automatischer Installer vorgesehen. Er soll die Einrichtung von G.R.E.A.T. vereinfachen und insbesondere Anwender:innen unterstützen, die bisher noch nicht mit Python und den zugehörigen Entwicklungswerkzeugen gearbeitet haben. Ziel ist es, technische Installationshürden abzubauen, damit sich die Anwender:innen stärker auf das konzentrieren können, wofür G.R.E.A.T. eigentlich entwickelt wurde:

Das systematische Erstellen sinnvoller Testfälle.

11. Open Source: Ausprobieren, Fehler melden und mitentwickeln

G.R.E.A.T. ist als Open-Source-Projekt auf GitHub verfügbar. Der Quellcode ist offen einsehbar, und wer möchte, kann sich auch an der Weiterentwicklung beteiligen. Ausdrücklich willkommen sind Fehlermeldungen, Verbesserungsvorschläge und eigene Beiträge zum Quellcode. Gerade bei einem Werkzeug für Softwaretester:innen wäre es schließlich schade, wenn es nicht selbst ausgiebig getestet würde. Vielleicht finden sich durch den praktischen Einsatz weitere sinnvolle Kombinatorikverfahren, neue Datenklassen oder Verbesserungen in der Bedienung.

Fazit: Weniger Kombinationsarbeit, mehr Zeit für gutes Testdesign

Systematisches Testdesign ist und bleibt eine anspruchsvolle Aufgabe. Wir müssen relevante Äquivalenzklassen identifizieren, Grenzwerte berücksichtigen, fachliche Zusammenhänge verstehen und geeignete Teststrategien auswählen. Gerade die anschließende Kombination von Testdaten ist jedoch eine Tätigkeit, bei der uns Werkzeuge erheblich unterstützen können. Hier setzt G.R.E.A.T. an. Es verbindet Äquivalenzklassen, Grenzwertanalyse, fachliche Regeln, unterschiedliche Kombinatorikverfahren und wiederverwendbare Testdaten mit der Möglichkeit, erzeugte Testfälle für manuelle oder automatisierte Tests zu exportieren.

Denn das Ziel ist nicht, möglichst viele Testfälle zu haben. Das Ziel ist, mit sinnvollen Testfällen möglichst viele relevante Fehler zu entdecken.

G.R.E.A.T. selbst ausprobieren

Das Werkzeug, den Quellcode sowie die Installationsanleitung gibt es kostenlos für die im Repository beschriebenen Nutzungsformen auf GitHub.

Zum GitHub-Repository:

https://github.com/TestGuru-DE/GreaT

Viel Spaß beim Experimentieren, Kombinieren und Testen!

Lizenz und Haftungshinweis

G.R.E.A.T. wird unter der AGPL-3.0 veröffentlicht. Die Projektdokumentation beschreibt kostenlose Nutzungsformen, darunter die private Nutzung, Lehre und interne Qualitätssicherung. Für bestimmte Formen kommerzieller Verwertung werden im Projekt zusätzlich gesonderte Vereinbarungen vorgesehen. Maßgeblich sind die im Repository veröffentlichten Lizenz- und Nutzungshinweise.

Die Software wird ohne Gewährleistung und ohne Anspruch auf Support bereitgestellt. Die Nutzung erfolgt auf eigenes Risiko. Eine Haftung ist im gesetzlich zulässigen Umfang ausgeschlossen. Anwender:innen sind selbst dafür verantwortlich, die Eignung und die erzeugten Ergebnisse für ihren Einsatzzweck zu prüfen.