Testmethoden: die passende Technik aus vier Gruppen

Testmethoden für den Testentwurf, im ISTQB-Deutsch Testentwurfsverfahren, sind strukturierte Verfahren, mit denen du Testfälle so auswählst, dass sich eine messbare Überdeckung des Testobjekts nachweisen lässt. Sie fallen in vier Gruppen: datenorientiert (Äquivalenzklassenbildung, Grenzwertanalyse), bedingungsorientiert (Entscheidungstabelle), prozessorientiert (Pfadtest) und am Erscheinungsbild orientiert (syntaktischer Test und nicht-funktionale Tests). Wer aus jeder Gruppe mindestens eine Technik kennt, greift bei einem Testproblem nicht zur falschen Methode.

Das Wichtigste in Kürze

• Wer Testentwurfsverfahren in vier Gruppen denkt (Daten, Bedingung, Prozess, Erscheinungsbild), erkennt zuerst, welche Gruppe zum Problem passt, und wählt erst danach die konkrete Technik.
• Zu viele Techniken auf einmal zu lehren, bringt nichts: TMAP hat den Einstiegskurs von 19 auf fünf Pflichttechniken verkleinert, damit die Teilnehmenden die Techniken wirklich anwenden können und nicht nur Prüfungswissen mitnehmen.
• Bedingungsorientierte Verfahren wie die Entscheidungstabelle laufen ins Leere, wenn das eigentliche Problem datenorientiert ist. Die falsche Gruppe liefert Testfälle mit wenig Wert, egal wie sauber die Technik angewendet wird.
• Im Unit-Test sagt die Entscheidungsüberdeckung mehr aus als die Zeilenüberdeckung, denn das Risiko steckt in den Entscheidungen der Programmlogik, nicht in einfachen Zuweisungen.

Warum Testmethoden gelernt und dann nicht genutzt werden

Fast jeder Tester kann ein paar Testmethoden aufzählen, im Alltag angewendet werden sie aber selten. Rik Marselis unterrichtet Testentwurfsverfahren seit fast 25 Jahren und sieht zwei Gründe für diese Lücke.

Der erste: Niemand fragt danach. Ist ein System in schlechtem Zustand, findest du Fehler mit dem ersten Knopfdruck. Eine strukturierte Technik scheint überflüssig, wenn die Fehler von selbst auftauchen.

Der zweite Grund wiegt auf Dauer schwerer. Ihren Wert zeigen Testentwurfsverfahren erst, wenn die Qualität schon gut ist oder wenn du eine belastbare Aussage über die Qualität treffen musst. Mit einer Technik kannst du belegen, welche Überdeckung du tatsächlich erreicht hast, und zwar bezogen auf das Risiko, um das es dir geht.

Zu viele Techniken sind Teil des Problems

Wer 15 bis 20 Techniken durchnimmt, bekommt Tester, die Prüfungen bestehen und danach nichts davon anwenden. Über ISTQB Foundation, Advanced Test Analyst und Advanced Technical Test Analyst hinweg begegnen einem zwischen 15 und 20 Testentwurfsverfahren. Rik und sein Kollege Bert kamen bei ihrer Recherche auf insgesamt etwa 25 bis 30. Die genaue Zahl ist Auslegungssache, weil manche Verfahren eher Varianten anderer sind als eigenständige Techniken.

Genau diese Menge ist die Falle. Frühere TMAP-Zertifizierungen verlangten, 19 Techniken und Ansätze zu beherrschen. In einem Dreitageskurs ist das nicht zu schaffen. Was du dort wirklich lernst, ist das richtige Kreuz bei A, B, C oder D. Wie du eine Technik anwendest, wenn die Lage unübersichtlicher ist als jede Prüfungsfrage, lernst du nicht.

Das überarbeitete TMAP-Zertifizierungsschema hat den Einstieg deshalb deutlich verkleinert. Der erste Kurs, Quality for Cross-Functional Teams, vermittelt fünf Techniken und einen Ansatz, dafür mit mehr Zeit und mehr Übungen. Am Ende sollen die Teilnehmenden die Techniken auf Einsteigerniveau tatsächlich anwenden können. Es geht darum, einmal eine Technik richtig zu lernen. An dieser Hürde scheitern viele Tester.

Testmethoden in vier Gruppen: eine Landkarte statt eines Katalogs

Jedes Testentwurfsverfahren gehört zu einer von vier Gruppen, und die Gruppen zu kennen ist wichtiger, als den ganzen Katalog auswendig zu lernen. Rik und Bert haben diese Struktur bei ihrer Recherche herausgearbeitet. Sie gibt dir eine Landkarte statt einer langen Liste.

• Prozessorientierte Techniken decken Abläufe durch ein System ab. Dazu gehört der Pfadtest mit seinen Stufen der Pfadüberdeckung, ebenso der Zustandsübergangstest mit Zustands- und Übergangsüberdeckung.
• Bedingungsorientierte Techniken gehen von Bedingungen zu Ergebnissen. Das klarste Beispiel ist die Entscheidungstabelle: Die Bedingungen bestimmen die Testfälle.
• Datenorientierte Techniken arbeiten mit Datenelementen und ihren Klassen. Hierher gehört die Äquivalenzklassenbildung.
• Erscheinungsbild umfasst alles, wie sich das System nach außen zeigt. Das reicht vom syntaktischen Test (Position der Buttons, Schriftart, Farben, Styleguide) bis zu nicht-funktionalen Aspekten wie Performance und Gebrauchstauglichkeit.

Als Faustregel reicht es, aus jeder Gruppe mindestens ein oder zwei Techniken zu kennen. Kennst du nur Techniken aus einer Gruppe, greifst du zwangsläufig irgendwann zum falschen Werkzeug.

Rik hat ein Team gecoacht, das sich auf den elementaren Vergleichstest festgelegt hatte, eine starke bedingungsorientierte Technik mit hoher Effizienz und Wirksamkeit. Das Team wollte sie überall einsetzen, und sie funktionierte immer wieder nicht. Der Grund war einfach: Das Problem war datenorientiert, und eine bedingungsorientierte Technik löst kein datenorientiertes Problem.

Das Starterset aus fünf Techniken

Ein brauchbarer Werkzeugkasten beginnt mit einer Technik pro Gruppe und einem erfahrungsbasierten Ansatz. Der TMAP-Einstiegskurs vermittelt fünf Techniken aus den vier Gruppen:

Ein zweiter Kurs, High-Performance Quality Engineering, ergänzt je Gruppe eine weitere Technik. Nach beiden Kursen hast du rund zehn Techniken und zwei Ansätze im Repertoire. Damit kommen etwa 90 Prozent der Tester durch ihr gesamtes Berufsleben.

Wie eine Vorlage beim Entscheidungstabellentest hilft

Eine gute Vorlage nimmt dir den schwersten Teil beim Lernen einer Technik ab: die Struktur von Grund auf aufzubauen. Der Entscheidungstabellentest war nach eigener Aussage eines langjährigen TMAP-Trainers immer schwer zu vermitteln. Eine Vorlage zum Herunterladen hat das geändert.

Mit der Vorlage musst du niemandem mehr beibringen, wie man die Tabelle zeichnet. Du zeigst, wie sie aussieht und was wohin gehört. Die Teilnehmenden tragen Bedingungen und Aktionen ein und leiten aus den Wahr-Falsch-Kombinationen das erwartete Ergebnis ab. Das erwartete Ergebnis ist der Kern jedes Testfalls, und die Vorlage führt direkt dorthin.

Beim Pfadtest funktioniert das genauso Schritt für Schritt. Du folgst den Schritten, kommst zu deinen Testfällen und kannst die erreichte Überdeckung nachweisen.

So wählst du die passende Testmethode für dein Testproblem

Vier Faktoren entscheiden, welche Technik passt, und das Risiko ist nur einer davon. Das TMAP-Buch nennt alle vier. Wer sie abwägt, greift nicht einfach zum Lieblingsverfahren.

Am Anfang steht die Art des Testproblems. Sie sagt dir, aus welcher Gruppe du wählst. Dann kommt das Qualitätsmerkmal: Geht es um Performance, landest du schnell in der Gruppe Erscheinungsbild. Der dritte Faktor ist das Risiko, und dafür reichen drei Stufen.

Beim Risiko lohnt es sich, dem Wunsch nach Zahlen zu widerstehen. Besteht jemand auf Prozentwerten, frag zurück, ob 72 Prozent wirklich etwas anderes bedeuten als 69. Niedrig, mittel, hoch genügt, denn die Techniken selbst bieten selten mehr als drei Stufen der Überdeckung. Höheres Risiko heißt mehr Überdeckung und eine gründlichere Technik.

Der vierte Faktor sind die Fähigkeiten der Beteiligten. Kennt das Team eine Technik nicht, hast du zwei Möglichkeiten: Du nimmst eine Technik, die das Team schon beherrscht, oder du bringst ihm die passende bei.

Testabdeckung und Erfahrung gehören zusammen

Die Überdeckung belegt, dass du alles Wichtige getestet hast. Die Erfahrung fängt auf, was die Überdeckung übersieht. Keins von beiden ersetzt das andere. TMAP empfiehlt seit Langem, erfahrungsbasierte Verfahren wie exploratives Testen mit strukturierten Testentwurfsverfahren zu kombinieren.

Rik hat das bei Business-Analysten erlebt, die den fachlichen Abnahmetest verantworten. Sie hatten gut beschriebene Prozessabläufe und waren damit wie gemacht für den Pfadtest, auch Prozesszyklustest genannt. In einer Sitzung von etwa anderthalb Stunden hat er ihnen die Technik gezeigt, eine Übung gemacht und ist dann für zwei Stunden mit einem ihrer echten Prozessabläufe zurückgekommen. Daraus haben sie gemeinsam die Testfälle abgeleitet.

Als die Analysten eine Situation entdeckten, die ihre Pfade nicht abdeckten, war die Antwort nicht, die Struktur über Bord zu werfen.

“Füg ruhig einen zusätzlichen Testfall aus deiner Erfahrung hinzu, aber wirf dafür keinen anderen weg, denn du brauchst deine Überdeckung.”

(Rik Marselis)

Hier treffen sich überdeckungsbasiertes und erfahrungsbasiertes Testen. Die Technik sichert die Basis. Die Erfahrung ergänzt, was die Technik nicht vorhersehen kann.

Warum Zeilenüberdeckung nicht reicht

Die Aussage “100 Prozent Überdeckung” ist wertlos, solange niemand fragt, welche Überdeckung gemeint ist. Entwickler schauen im Unit-Test oft auf die Codeüberdeckung und hören bei der Zeilenüberdeckung auf. Diese Zahl lässt sich leicht schönrechnen: fünf Anweisungen in eine Zeile schreiben, eine davon ausführen, und schon meldet das Werkzeug 100 Prozent für diese Zeile.

Der nächste Schritt ist die Anweisungsüberdeckung, bei der jede Anweisung mindestens einmal ausgeführt wird. Noch besser ist die Entscheidungsüberdeckung, denn Entscheidungen sind die wichtigsten Anweisungen im Code. Eine einfache Zuweisung, die einer Variablen einen Wert gibt, birgt wenig Risiko. Bei if-Anweisungen und while-Schleifen willst du dagegen wissen, dass sowohl der Gutfall als auch der Fehlerfall funktionieren.

Dafür reichen einfache Techniken. Mit der Äquivalenzklassenbildung bekommst du eine Klasse für das richtige und eine für das falsche Ergebnis und zu jeder einen Testfall. Das wiederkehrende Problem: Viele Entwickler testen nur den Gutfall und vergessen den Fehlerfall.

Das ist weniger eine Frage der Anleitung als des Bewusstseins. Sagst du einem Entwickler, er solle testen, was bei einer falschen Eingabe passiert, stimmt er meist zu und merkt dann, dass sich die Zahl der Testfälle verdoppelt. Stimmt. Genau darum geht es.

Alte Techniken, und der Pfadtest wird immer noch zu wenig genutzt

An den Testentwurfsverfahren selbst hat sich seit Jahrzehnten wenig geändert. Offen ist nur, wie verbreitet sie sind. Die grundlegenden Techniken stehen in Büchern, die mehr als 20 Jahre alt sind. Glenford Myers hat Grenzwertanalyse und Äquivalenzklassenbildung vor rund 45 Jahren in The Art of Software Testing beschrieben. Die Arbeiten von Boris Beizer und die früheren TMAP-Bücher bilden den Rest dieser Linie, auf die sich das ISTQB bis heute bezieht.

Eine Lücke fällt auf. Als prozessorientierte Technik lehrt das ISTQB den Zustandsübergangstest, und der dreht sich um Zustände. Nur wenige Systeme haben aber aussagekräftige Zustände, und im Abnahmetest geht es meist um Abläufe, also um die Geschäftsprozesse durch ein System. Genau die deckt der Pfadtest ab, trotzdem ist er längst nicht so verbreitet, wie er sein könnte. Die Business-Analysten, die Rik begleitet hat, haben ihn sofort angenommen, weil er zu ihrem Blick auf das System passte.

Wann sich die höchste Testabdeckung lohnt

Der elementare Vergleichstest liefert die höchste verfügbare Überdeckung, erkauft mit mehr Komplexität. Neben Pfadtest und Entscheidungstabelle gehört er zu Riks drei Lieblingstechniken, aber man wählt ihn nicht nebenbei.

Entscheidungstabellen sind stark, wenn du alle Möglichkeiten testen willst. Ihre Grenze: Ab etwa fünf Bedingungen werden sie unhandlich. In der Praxis hängen aber nur wenige Ergebnisse von fünf Bedingungen gleichzeitig ab, deshalb trägt die Technik meistens.

Der elementare Vergleichstest prüft mehrere Entscheidungspunkte. Für jeden Entscheidungspunkt leitet er mit der modifizierten Bedingungs-/Entscheidungsüberdeckung die Testsituationen ab und kombiniert diese dann über alle Entscheidungspunkte zu vollständigen Testfällen von Anfang bis Ende. Wo der Pfadtest mehrere Bedingungskombinationen auf demselben Pfad zu einem einzigen Testfall zusammenfasst, deckt der elementare Vergleichstest alle Kombinationen ab. Das ergibt mehr Testfälle und das größte Vertrauen, dass das System funktioniert, wenn sie bestanden sind. Um ihn gut zu lernen, brauchst du etwa einen Workshop-Tag, und Vorlagen geben die Struktur vor.

Häufig gestellte Fragen

Wie viele Verfahren für den Testentwurf gibt es, und wie viele braucht ein Tester tatsächlich?

Studien beziffern die Gesamtzahl auf etwa 25 bis 30 Verfahren, und selbst diese Zahl ist umstritten, da es sich bei einigen eher um Varianten als um eigenständige Verfahren handelt. In den ISTQB-Zertifizierungen „Foundation“, „Advanced Test Analyst“ und „Advanced Technical Test Analyst“ lernt man 15 bis 20 davon kennen. Etwa zehn Testverfahren plus zwei Ansätze decken das ab, was rund 90 Prozent der Tester im Laufe ihrer Karriere benötigen.

Lohnt es sich, strukturierte Verfahren für den Testentwurf anzuwenden, wenn ein System bereits voller offensichtlicher Fehlerzustände ist?

In dieser Situation bringen sie kaum einen Mehrwert. Wenn ein System in einem schlechten Zustand ist, treten Fehler schon beim Drücken einer Taste zutage, sodass niemand nach einer strukturierten Methode fragt. Der Nutzen zeigt sich erst, wenn die Qualität bereits gut ist oder wenn jemand eine überzeugende Antwort zur Qualität verlangt, denn mit einer Technik kannst du zeigen, welche Überdeckung du erreicht hast und wie diese mit dem für dich relevanten Risiko zusammenhängt.

Was läuft schief, wenn sich ein Team bei allem auf ein einziges Lieblings-Testverfahren verlässt?

Die Technik wird auf Probleme angewendet, die sie nicht lösen kann. Ein von Rik Marselis gecoachtes Team hatte sich auf den elementaren Vergleichstest festgelegt, eine starke, bedingungsorientierte Technik, und wollte ihn überall einsetzen. Es war immer wieder fehlgeschlagen, weil ihr Problem datenorientiert war, und keine noch so große Sorgfalt kann diese Diskrepanz beheben. Wenn man ein oder zwei Techniken aus jeder der vier Gruppen kennt, lässt sich das vermeiden.

Welche Techniken bilden einen sinnvollen Einstiegssatz für jemanden, der neu im Testentwurf ist?

Eine Technik pro Gruppe plus ein erfahrungsbasierter Ansatz: Äquivalenzklassenbildung und Grenzwertanalyse für Daten, Pfadtests für Prozesse, die Entscheidungstabelle für Bedingungen, syntaktische Tests für das Erscheinungsbild und ein explorativer Test als erfahrungsbasierter Ansatz. Fünf Techniken mit ausreichend Übungszeit sind besser als neunzehn, die man für eine Prüfung auswendig lernt, denn die meisten Tester kommen nie darüber hinaus, eine einzige richtig zu beherrschen.

Sollte das Risiko als Prozentsatz quantifiziert werden, wenn man entscheidet, wie gründlich getestet werden soll?

Nein. Drei Stufen reichen aus: niedrig, mittel und hoch. Wenn jemand auf Zahlen besteht, frag, ob sich 72 Prozent sinnvoll von 69 unterscheiden. Die Techniken selbst bieten selten mehr als drei Stufen der Überdeckung, daher hat eine feinere Skala keine Grundlage. Ein höheres Risiko bedeutet einfach mehr Überdeckung und eine gründlichere Technik.

Bedeutet eine Codeüberdeckung von 100 Prozent, dass der Code gut getestet ist?

Nicht an sich, denn die Zahl hängt davon ab, welche Art von Überdeckung gemeint ist. Die Zeilenüberdeckung lässt sich leicht manipulieren: Man schreibt fünf Anweisungen in eine Zeile, führt eine davon aus, und die Zeile wird als vollständig abgedeckt gemeldet. Die Anweisungsüberdeckung ist besser, die Entscheidungsüberdeckung noch besser, da „if“-Anweisungen und „while“-Schleifen das eigentliche Risiko bergen, während eine „move“-Anweisung, die einen Wert zuweist, dies nicht tut.

Kann explorativer Test strukturierte Testentwürfe ersetzen?

Nein, beides gehört zusammen. Die Überdeckung beweist, dass alles Relevante getestet wurde; die Erfahrung deckt auf, was das Modell nicht vorhersehen kann. Wenn Tester eine Situation entdecken, die ihre Pfade nicht abdecken, lautet der Rat, einen zusätzlichen Testfall auf der Grundlage der Erfahrung hinzuzufügen und die bestehenden beizubehalten, damit die Überdeckung intakt bleibt.

Was bietet der elementare Vergleichstest, was das Pfadtesten nicht bietet?

Er testet Bedingungskombinationen, die beim Pfadtesten zusammengefasst werden. Beim Pfadtesten werden mehrere Kombinationen, die denselben Pfad teilen, zu einem Testfall zusammengefasst, während der elementare Vergleichstest an jedem Entscheidungspunkt eine modifizierte Bedingungs-/Entscheidungsüberdeckung anwendet und diese Situationen über alle Entscheidungspunkte hinweg zu vollständigen Testfällen kombiniert. Das Ergebnis sind mehr Testfälle, die höchstmögliche Überdeckung und ein etwa eintägiger Workshop zum Erlernen der Methode.