Chat with us, powered by LiveChat

Tappe nicht in die Grenzwert-Falle! (Beitrag zum ISTQB CTFL SYLLABUS 4.0)


Last updated: 13.11.23
Tappe nicht in die Grenzwert-Falle! (Beitrag zum ISTQB CTFL SYLLABUS 4.0)

Als erfahrene Tester wissen wir alle, wie Äquivalenzklassen und Grenzwerte uns beim Testfalldesign helfen können. Insbesondere die Grenzwertanalyse (GWA) lenkt unsere Aufmerksamkeit auf Werte, die eine hohe Wahrscheinlichkeit haben, Fehler zu finden – Fehler, welche die Entwickler möglicherweise einfach durch die Verwendung des falschen relationalen Operators implementiert haben. Schauen wir uns das mal an:

Angenommen, wir möchten die Implementierung der folgenden Anforderung testen: "Wenn Sie 18 Jahre oder älter sind, können Sie bei uns eine Kfz-Versicherung abschließen". Die Grenze liegt bei "Alter = 18", also würden wir es mit 17 (wo wir erwarten, dass wir KEINE Kfz-Versicherung beantragen können) und 18 (wo wir erwarten, dass wir eine Kfz-Versicherung beantragen können) testen. Die folgende Tabelle fasst die Testfälle (TFs) für diesen Ansatz zusammen:

Beispiel zur Testfallermittlung mittels Grenzwertanalyse im Softwaretest (Tabelle 1)

 

Der obige Ansatz (1) zeigt das erwartete Ergebnis bei korrekter Implementierung. Aber schauen wir uns auch mal an, wie die Ergebnisse für die beiden Testdaten-Werte 17 und 18 aussehen, wenn der Entwickler diese Entscheidung – fehlerhafterweise – mit einem falschen relationalen Operator umgesetzt hat:

Beispiel zur Testfallermittlung mittels Grenzwertanalyse im Softwaretest (Tabelle 2)

 

Da TF (1) und (6) für die Eingabewerte 17 und 18 die gleichen Ergebnisse liefern, wird die fehlerhafte Implementierung (x = 18) nicht erkannt. Dazu bräuchten wir einen dritten Testfall, z.B. den Eingabewert 19. TF (1) gibt ein wahres, TF (6) ein falsches Ergebnis für den Eingabewert 19, so dass der falsche relationale Operator erkannt werden kann.

So weit, so gut. Deshalb testen wir Hochrisikoanwendungen mit DREI Werten pro Grenze, das wissen wir alle. Das ist nichts Neues, also wo ist der Haken? 

 

Der Unterschied zwischen "Abdeckungswerte pro Grenze" und "Abdeckungswerte pro Grenzwert"

 

Schauen wir uns den ISTQB CTFL Syllabus 4.0 an, dort heißt es: "In der 3-Wert-Grenzwertanalyse gibt es für jeden Grenzwert drei Überdeckungselemente: den Grenzwert und seine beiden Nachbarn. [...] Um bei der 3-Wert-Grenzwertanalyse eine 100%ige Überdeckung zu erreichen, müssen die Testfälle alle Überdeckungselemente, d. h. die identifizierten Grenzwerte und deren Nachbarn, ausführen." Nun, in dieser neuen Version des ISTQB-Lehrplans (v4.0) ist explizit nicht von "drei Abdeckungswerten pro Grenze" die Rede, sondern von "drei Abdeckungswerten pro Grenzwert". Und das ändert die Regeln deutlich: 
Erinnere Dich, dass wir in der alten Definition der 3-Wert-GWA die Grenze von 18 mit DREI Überdeckungselementen getestet haben: 17, 18 und 19 (wie oben gezeigt). Jetzt aber müssen wir für die 3-Wert-GWA drei Überdeckungselemente pro Grenzwert verwenden. Die Grenzwerte im obigen Beispiel sind 17 und 18. Für den unteren Grenzwert von 17 sind daher die Überdeckungselemente 16, 17 und 18 und für den oberen Grenzwert von 18 sind die Überdeckungselemente 17, 18 und 19 (die Grenze und ihre Nachbarn). Deshalb gilt: Die korrekte Umsetzung der 3-Wert-GWA benötigt VIER Testfälle: 16, 17, 18 u. 19 !

Dieser Ansatz mit vier Überdeckungselementen pro Grenze hat einen weiteren Vorteil: Das Black-Box-Testfalldesign verwendet die Spezifikation (s.o.) als Testgrundlage, daher ist 18 die Grenze und 17 und 18 sind die Grenzwerte. Wir Tester wissen aber nicht, wie die Entwicklung diese Bedingung umgesetzt hat. Statt "wenn x >= 18, dann..." könnte sie es auch wie in TF (7) gezeigt umgesetzt haben: "wenn x > 17 dann..." – was funktional äquivalent ist. Bei Black-Box-Tests wissen wir nicht, welche Implementierung gewählt wurde. Schaue Dir vor diesem Hintergrund jetzt mal die folgende Tabelle an:

Beispiel zur Testfallermittlung mittels Grenzwertanalyse im Softwaretest (Tabelle 3)

 

Wenn Du diese Implementierung mit dem alten 3-Wert-GWA-Ansatz testest, bei dem 17, 18 und 19 als implementierte Überdeckungselemente (7) verwendet werden, wird die falsche Kodierung in (12) nicht erkannt. Der überarbeitete Ansatz mit vier Überdeckungselementen (16, 17, 18, 19) zeigt jedoch den Fehler: Er ergibt 16/falsch für TF (7) und 16/wahr für TF (12).

Durch das Testen von Hochrisiko-Anwendungen mit vier statt drei Überdeckungselementen pro Grenze können Fehler erkannt werden, die sonst möglicherweise übersehen werden. Am Ende musst Du – als gut ausgebildeter und erfahrener Tester – eine Entscheidung treffen, welche Methode Du wählst. Dazu müssen viele Faktoren berücksichtigt werden, jetzt kennst Du einen weiteren.

Wenn Du mehr über die Testfallermittlung unter Zuhilfenahme von Grenzwerten erfahren möchtest ("Grenzwertanalyse"), dann besuche eine unserer ISTQB-Foundation-Level-Schulungen online oder in Deiner Wunsch-Stadt. Ab 2024 nach neuem ISTQB-Foundation-Level-Lehrplan Version 4.0.