ER-Modellierung für eine klareTestnomenklaturIn diesem Artikel wird ein beispielhaftes ER-Diagramm für viele testrelevante Artefakte entworfen und der Nutzen demonstriert.Hierfür werden besonders relevante Entitäten, welche im ISTQB®-Glossar definiert sind, in ER-Diagrammen dargestellt und derenBeziehungen soweit möglich aus der Beschreibung des Testprozesses im ISTQB®-Lehrplan abgeleitet. Im Abschluss diskutiertder Autor die Nutzungsmöglichkeiten solcher ER-Diagramme.

sich auf einen Testfall. Die Herausfor -derung besteht darin, objektive Kriterienfür die Auswahl der Testfälle zu finden.Testfälle sollten aus heutiger Sicht Testbe -din gungen überdecken [Black99], welchesich ihrerseits an Testzielen orientieren.

Im Vortrag [ThSm07] zeigen die Au -toren, dass sich die Entitäten des Testens inder umfangreichen Fachliteratur erst all-mählich entwickelt haben und vor ISTQB®

noch keine Einigkeit darüber herrschte.Obwohl diese Autoren die Notwendigkeiteines ER-Modells betonen, entwerfen sienur ein bruchstückhaftes Klassenmodellund stellen die Machbarkeit eines festenEntitätsmodells in Frage.

Das Buch [Koom06] enthält ein kleinesER-Diagramm mit Beziehungen in Krähen -fuß-Notation und mit Swimlanes, welches– in ISTQB-Nomenklatur übersetzt – inAbbildung 1 dargestellt ist.

In der Testmethode TMap NEXT® habendie Kernentitäten demnach folgendeBeziehungen:

n Eine Testbedingung wird typischer-weise durch mehrere abstrakte Testfälleüberdeckt, und ein Testfall kann meh-rere Testbedingungen abdecken.

n Zu einem abstrakten Testfall gibt esgenau einen konkreten Testfall.

zu anderen Entitäten wie Testbasis,Anforderung, Testskript usw.? Ein ER-Diagramm könnte hier helfen, die Entitätenund ihre Beziehungen eindeutig, übersicht-lich und verständlich darzustellen, und soll-te Teil der Standards werden.

Eine naheliegende AufgabeStellen wir uns folgendes Szenario vor:Unsere Abteilung soll eine ISTQB-basierteTestmethode für die Testorganisation imUnternehmen festlegen. Der Abteilungs -leiter beauftragt uns dabei mit der Ent -wicklung eines ER-Modells der Test -entwicklung. In diesem konzeptuellenMo dell sollen wir die Entitäten von denAnforderungen über Testfälle bis hin zuden Fehlermeldungen und ihreBeziehungen, insbesondere die Überde -ckung und Rückverfolgbarkeit, eindeutigund verständlich für unsere Software -entwicklungsorganisation festlegen. Wirentscheiden uns für die Darstellung alsUML-Klassendiagramm.

Relevante LiteraturDer Testfall als zentraler Begriff tauchtbereits im ersten Buch zum Softwaretestenauf [Hetz73]. Im einfachsten Modell wirddas Testobjekt durch einige Testfällegeprüft, und jeder gefundene Fehler bezieht

Entity-Relationship(ER)-Diagramme sindin der Modellierung von Geschäfts pro -zessen weit verbreitet. Sie definieren eineklare Nomenklatur und helfen damit beimVerständnis und bei der Qualitätssicherungvon Geschäftsentitäten und ihren Be -ziehungen. Die Analyse, Entwicklung undDurchführung von Softwaretests kannselbst als Geschäftsprozess betrachtet wer-den. Die bekanntesten Beschreibungen derSoftwaretestentwicklung enthalten jedochentweder gar kein Modell (wie der Lehr -plan ISTQB®) oder nur ein sehr rudimentä-res Modell (wie die Methode TMapNEXT®). Sie beschränken sich auf die meistnatürlichsprachliche Beschreibung der ein-zelnen Entitäten und der Prozesse und las-sen dabei die Kardinalitäten oft imUnklaren.

Die diesem Bereich zuzuordnenden Test -glossare enthalten heute bereits einebeträchtliche Anzahl an Begriffen, welchein der Testentwicklung eine unmittelbareRolle spielen, mitsamt ihren Definitionen.Zum Beispiel ist der Kernbegriff desSoftwaretestens natürlich der Testfall. Aberin welcher Beziehung steht dieser Testfall

der au tor

Dr. Matthias Hamburg

(matthias.hamburg@sogeti.de)ist ein langjährig erfahrener Experte für Testprozessberatung und arbeitet seit 2006 bei Sogeti Deutschland GmbH. Er ist Full Advanced zertifizierter Tester und leitet die Arbeitsgruppe Glossar im German Testing Board (GTB), dem Gremium, welches Deutschland im International Software Testing Qualifications Board(ISTQB®)1) vertritt.

1 www.objektspektrum.de

advertorial

1) ISTQB® ist eine registrierte Marke vonInternational Software Testing Qualifications Board.TMap NEXT® ist eine registrierte Marke von SogetiNederland B.V.

n Abstrakter und konkreter Testfall sindSpezialisierungen der Klasse „Testfall“.

n Ein konkreter Testfall kann als Schrittin mehreren Testskripten vorkommen,und ein Testskript kann mehrere kon-krete Testfälle enthalten.

Die Kardinalität der Beziehung zwischenabstraktem und konkretem Testfall wirdhäufig diskutiert. Wir werden später in die-sem Artikel darauf zurück kommen.

Ein anderer diesem Thema dedizierteArtikel [Kent08] entwirft ein konzeptuellesER-Modell mit sieben Entitäten: Spezifi -kationseinheit, Testbededingung, Testfall,Testschritt, Testskript, Testausführungs -plan und Testergebnis. Obwohl sich derAutor explizit auf ISTQB® beruft, weichtsein Klassenmodell davon ab. Zum Beispielbenutzt er die Entität Testschritt, die imISTQB® [ISTQB-Gloss14] nicht vorkommt.Auch dieser Artikel betont den vorläufigenCharakter der Ergebnisse: „Das Testentitä -ten modell ist keineswegs vollständig“.

Von der Anforderungzum TestfallFür ein umfassendes ER-Modell nachISTQB® wollen wir im ersten Schritt dieEntitäten Anforderung und Testfall untersu-chen, wie sie in der Phase Testanalyse und -entwurf des fundamentalen Test pro zesses[ISTQB-FL11] vorkommen. Wir betrachtendie Definitionen aus [ISTQB-Gloss14] (inkursiv) und erläutern sie durch Beispiele.

n Anforderung: Eine vom Benutzer benö-tigte Eigenschaft oder Fähigkeit, dieeine Software erfüllen oder besitzen

muss (…) Beispiel: Wenn der Benutzergültig angemeldet ist, soll ihm dasSystem erlauben, sein Passwort in eingültiges neues Passwort zu ändern.

n Testfall: Umfasst folgende Angaben: diefür die Ausführung notwendigen Vor -be dingungen, die Menge der Ein -gabewerte (ein Eingabewert jeParameter des Testobjekts), die Mengeder vorausgesagten Ergebnisse, sowiedie erwarteten Nachbedingungen. Test -fälle werden entwickelt im Hinblick aufein bestimmtes Ziel beziehungsweiseauf eine Testbedingung, wie z.B. einenbestimmten Programmpfad auszufüh-ren oder die Übereinstimmung mit spe-zifischen Anforderungen zu prüfen (wieEingaben an das Testobjekt zu überge-ben und Sollwerte abzulesen sind).Beispiel: Vorbedingung: Benutzer istgültig angemeldet. Eingabewerte: gülti-ges neues Passwort. VorausgesagtesErgebnis: Bestätigung. Erwartete Nach -bedingung: Benutzer kann sich bei dernächsten Anmeldung nur mit dem neu-en Passwort anmelden.

Im zweiten Satz der Definition des Testfallserkennen wir weitere verbundene Enti -täten:

n Testobjekt: Die Komponente oder dasSystem, welches getestet wird. Beispiel:Berechtigungssystem.

n Testziel: Ein Grund oder Zweck fürden Entwurf und die Ausführung vonTests. Beispiel: Verifiziere, dass das Be -rechtigungssystem alle spezifiziertenAnforderungen erfüllt.

n Testbedingung: Eine Einheit oder einEreignis, (…) welches durch einen oder

mehrere Testfälle verifiziert werdenkann. Beispiel: Passwortänderung mitEingabe eines gültigen neuen Pass -worts.

Wir interpretieren die Definition derTestbedingung in dem Sinne, dass sie dieje-nige Entität ist, welche ausdrückt, wasdurch Testfälle abgedeckt werden soll.Testbedingungen sind folglich spezifisch fürein Testziel. Zwischen Testbedingung undAnforderung sollte andererseits eineRückverfolgbarkeitsbeziehung bestehen.

Bevor wir zum Klassendiagramm kom-men, stellen wir zwei weitere Aspekte fest. In unserem Unternehmen werden Test -objekte beim Testen typischerweise inTeilobjekte untergliedert. Zum Beispielwerden sich in einem Systemtest dieTestfälle auf die verschiedenen Use Casesbeziehen. Als passende Entität im ISTQB®

finden wir:

n Testeinheit: Das einzelne Element, dasgetestet wird. Gewöhnlich existierenein Testobjekt und viele Testelemente.Beispiel: Use Case „Passwort erfassen“.

Des Weiteren wollen wir die Beziehungzwischen abstrakten und konkreten Test -fällen festlegen. Wir entscheiden uns fürden folgenden Ansatz:

n Beim Testentwurf werden die Testfälleals abstrakte Testfälle entworfen.

n Konkrete Testfälle werden erst in derTestrealisierung zu jedem abstraktenTestfall erstellt. Die Kardinalität dieserBeziehung werden wir bei der Test -realisierung und -durchführung festle-gen.

2Online-Themenspecial Testing 2014

Online-Themenspecial Testing 2014 advertorial

Abb. 1: ER-Modell in TMap NEXT®

Abb. 2: ER-Diagramm für Testanalyse und Testentwurf

neuen Passwort „HaSm45.6“ anmel-den.

n Testzyklus: Durchführung des Test -prozesses für ein einzelnes bestimmtesRelease des Testobjekts. Beispiel:Durchführung aller Testfälle aufRelease 1.3 des Berechtigungssystems.

n Testprotokoll: Eine chronologischeAufzeichnung von Einzelheiten derTestausführung. Beispiel: Protokoll derAusführung des Tests auf Berechti -gungssystem Release 1.3, mit denDurchf ührungen der Testskripte undkonkreter Testfälle.

n Fehlerbericht: Ein Dokument, das übereinen Fehlerzustand einer Komponenteoder eines Systems berichtet (…).Beispiel: Nach dem Versuch der Ände-rung des Passworts in ein ungültigesPasswort kann sich der Benutzer nichtmehr mit dem alten Passwort anmel-den.

Die Kardinalität des Testprotokolls bleibtin obiger Definition unklar. Wir legen dasso aus, dass es pro durch geführ tem Test -skript ein Testprotokoll gibt.

Nun wollen wir auch die oben erwähnteBeziehung zwischen abstraktem und kon-kretem Testfall klären. Die Erfahrung zeigt,dass ein Testfall nicht immer mit den glei-chen konkreten Testdaten durchgeführtwerden kann. Unsere Entscheidung ist folg-lich, dass ein abstrakter Testfall proDurchführung unterschiedlich konkreti-siert werden kann.

Des Weiteren fehlt uns eine Entität, dieeine Durchführung eines Testskripts ineinem Testzyklus darstellt. Diese Lücke

n Testumgebung: Eine Umgebung, die be -nötigt wird, um Tests auszuführen. Bei -spiel: Angaben zum Browser, Be triebs -system, Webserver, Middleware usw.

Die ersten drei Entitäten sind aus Sichteines ER-Modells redundant, da wir inunserem Modell weder zwischen automati-scher und manueller Durchführung nochzwischen Entität und ihrer Dokumentationdifferenzieren wollen. Wir entscheiden unsdeshalb dafür, nur das Testskript im Modelldarzustellen.

Für die Testdurchführung brauchen wirneben der Testumgebung noch weitereEntitäten. Der gleiche Testfall kann mitmehreren Versionen des Testobjekts durch-geführt werden. Dazu passt im [ISTQB-Gloss14] die Entität Testzyklus. Schließlichsind die Ergebnisse der Durch führung dasTestprotokoll und der Fehlerbericht.

n Abstrakter Testfall: Ein Testfall ohnekonkrete Ein- und Ausgabewerte fürEingabedaten und vorausgesagte Er -gebnisse. Beispiel: siehe oben beimTestfall.

n Konkreter Testfall: Ein Testfall mitkonkreten Werten für Eingaben undvorausgesagte Ergebnisse. Beispiel:Vorbedin gung: Benutzer „HansSchmitz“ ist gültig angemeldet, aktuel-les Passwort ist „HaSchm12.3“.Eingabewerte: gültiges neues Passwort„HaSm45.6“. Voraus gesagtes Ergeb -nis: Bestätigung „Das Passwort wurdegeändert“. Erwartete Nachbedingung:Benutzer „Hans Schmitz“ kann sich beider nächsten An meldung nur mit dem

Abbildung 2 zeigt unser ER-Diagramm fürTestanalyse und -Entwurf, mit zwei Swimlanes für die Aktivitäten Testanalyseund -ent wurf.

Die Beziehungen in diesem Diagrammenthalten weitere Informationen, zumBeispiel:

n Ein Testobjekt besteht aus 1 bis n Test -einheiten. Eine Testeinheit existiertimmer nur als Teil eines Testobjekts.

n Eine allgemeine Viele-zu-viele-Bezie -hung der Testbedingungen zu Anfor -derungen stellt die Rückverfolgbarkeit(Traceability) beim Testen sicher.

n Jede Testbedingung ist durch mindes -tens ein Testziel begründet.

n Ein abstrakter Testfall kann mehrereTestbedingungen überdecken. Das isteine pragmatisch freimütige Interpre -tation der ISTQB-Definition: Wir wol-len mit wenigen Testfällen möglichstviele Testbedingungen überdecken.

n Ein abstrakter Testfall kann mehrereTestziele verifizieren. Auch das ist einepragmatische Interpretation derISTQB-Definition.

Entitäten der Testrealisierungund Testdurchführung„Testrealisierung und -durchführung ist dieAktivität, bei der unter Berücksichtigungaller anderen Informationen, die zurTestdurchführung nötig sind, Testabläufeund Testskripte spezifiziert werden, indemTestfälle in einer besonderen Reihenfolgekombiniert werden. Des Weiteren wird dieTestumgebung in dieser Phase entsprechendkonfiguriert und genutzt.“ [ISTQB-FL11]

Wir erkennen in dieser Aktivitätsbe -schrei bung folgende Entitäten:

n Testablauf: Siehe Testablaufspezi fika -tion.

n Testablaufspezifikation: Ein Doku -ment, das eine Folge von Schritten zurTestausführung festlegt. Auch bekanntals Testskript oder Testdrehbuch.Beispiel: Schritt 1: Testfall, in dem sichder Benutzer anmeldet (altes Passwort);Schritt 2: Testfall, in dem der Benutzerdas Passwort ändert; Schritt 3: Testfall,in dem sich der Benutzer abmeldet;Schritt 4: Testfall, in dem sich derBenutzer anmeldet (neues Passwort).

n Testskript: Bezeichnet üblicherweiseeine Testablaufspezifikation, insbeson-dere eine automatisierte. Beispiel: SieheTestablaufspezifikation.

advertorial

3 www.objektspektrum.de

Abb. 3: ER-Diagramm für Testrealisierung und Testdurchführung

werden wir selbst schließen müssen, ISTQBhilft nicht weiter.

Damit ergibt sich das ER-Diagramm inAbbildung 3 für die Entitäten der Test -realisierung und -durchführung.

SchlussfolgerungDie ER-Modellierung sichert die Qualitätder Kernbegriffe des Testens in einemTestprozess. Bei unserer beispielhaftenModellierung haben wir Ambiguitäten,Redundanzen und Lücken erkannt undaufgelöst, bevor sie im Prozess zumProblem führen.

Im Falle des ISTQB® ist der Autor sicher,dass verschiedene Personen zu verschiede-nen Ergebnissen kommen können. Mankann etwa unterschiedliche Ansichten darü-ber haben, welche der zahlreichen in[ISTQB-FL11] und [ISTQB-Gloss14] er -wähnten Entitäten die Richtigen sind. Dasliegt daran, dass ISTQB® keine einzelneMethode, sondern eine Wissenssammlungist. Gerade deshalb ist es sinnvoll, im Falleeiner ISTQB-basierten Testmethode ein eige-

nes ER-Modell abzuleiten. Die Intention desAutors war zu zeigen, dass dies nützlich undmit vertretbarem Aufwand machbar ist.Darüber hinaus wäre auch ein generischesISTQB-ER-Modell wünschenswert.

DankDie Idee zu diesem Artikel ist durch frucht-bare Diskussionen über Testbegriffe mit

Kollegen von der Robert Bosch GmbH ent-standen. Der Autor dankt Dr. ReinhardWolf, Dr. Markus Prechtel, Jochen Burk -hart und Rainer Kielkopf für dieseAnregung. Dank gilt auch Dr. Frank Simonvom German Testing Board für die Ermun -terung zu diesem Artikel und für seineAnmerkungen. n

4Online-Themenspecial Testing 2014

Online-Themenspecial Testing 2014 advertorial

Literatur & Links

[Black99] R. Black, Managing the Testing Process, Microsoft Press, 1999

[Hetz73] W. C. Hetzel (Hrsg.), Program Test Methods, Prentice Hall, 1973

[ISTQB-FL11] ISTQB: Certified Tester Foundation Level Syllabus, Version 2011,

www.german-testing-board.info

[ISTQB-Gloss14] ISTQB/GTB-Standardglossar der Testbegriffe, Version 2.3, April 2014,

www.german-testing-board.info

[Kent08] J. Kent, An Entity Model of Software Testing, EuroSTAR 2008, Präsentation verfügbar

auf www.simplytesting.com

[Koom06] T. Koomen et al., TMap NEXT, UTN Publishers, 2006

[ThSm07] N. Thompson, M. Smith, Holistic Test Analysis & Design, STARWest 2007,

Präsentation verfügbar auf www.slideshare.net