Modellbasierte FachtestsTest-Driven Development für DomänenexpertenIn vielen Projekten sind manuelle Akzeptanztests durch die Fachexperten Realität. Aufgrund des hohen Aufwands werden dieseTests sehr selten und eher spät im Entwicklungszyklus ausgeführt. Spätes und seltenes Feedback führt jedoch unweigerlich zuAbweichungen gegenüber den Anforderungen. Ein modellbasiertes Werkzeug unterstützt demgegenüber den Fachexperten beider Beschreibung automatisierbarer Testfälle in „seiner Sprache“. Die Entwickler können diese Testfälle kontinuierlich ausführenund auf dieser Basis akzeptanztestgetrieben entwickeln.

Form von Tests beziehungsweise Übungs-aufgaben geprüft wird. Je länger sich etwasFalsches oder falsch Verstandenes beimSchüler manifestiert, umso schwerer wirddie Korrektur des Wissens. ContinuousIntegration (CI) [Fowl06] überträgt dieseErkenntnis auf die Softwareentwicklung,indem die Softwareentwickler Tests für eineAnwendung definieren, die im Idealfall beijeder Änderung am Quellcode ausgeführtwerden. Die Metapher der kontinuierlichen

In der Softwareentwicklung verhält essich analog. Ob die Domäne und dieAnforderungen richtig verstanden undumgesetzt wurden, lässt sich am Bestendurch Tests ermitteln. Diese „Übungsauf-gaben für die Software“ werden durch dieDomänenexperten (also die späteren An -wender) definiert und konfrontieren dieSoftware mit realen Problemstellungen.

Beim Erlernen einer Sprache ist es nütz-lich, wenn der Lernerfolg kontinuierlich in

Software entsteht durch einen Überset-zungsprozess funktionaler Anforderungenin eine technische Implementierung.Während der Entstehung versuchen dieSoftwareentwickler, die Fachdomäne derzukünftigen Anwender und die aus dieserDomäne entstehenden Anforderungenmöglichst gut zu verstehen. Ob dieDomäne und die Anforderungen richtigverstanden worden sind, lässt sich ameffektivsten ermitteln, indem die Soft -wareentwickler „Was wir verstandenhaben“ in Form von funktionsfähiger Soft -ware vorstellen und die zukünftigenAnwender ihnen anhand dieser SoftwareFeedback geben.

Warum lohnen sichhäufige Tests?Die Situation der Softwareentwickler ist ver-gleichbar mit der von Schülern oderErwachsenen, die beispielsweise eine neueFremdsprache lernen. Auch diese Personensind auf Feedback derjenigen angewiesen, dieihnen die Sprache beibringen. Damit dasFeedback objektiv und nachvollziehbar ist,wird der Lernerfolg in Form von Testsermittelt. Die Schüler sehen an den Er -gebnissen der Tests sofort Defizite und kön-nen die Tests im Idealfall auch im Selbst -studium wiederholen („Übungsaufgaben“).

der au tor

Konstantin Diener

(konstantin.diener@cofinpro.de)ist Leading Consultant bei der Cofinpro AG. Er beschäftigt sich seit überzehn Jahren mit Softwarearchitektur und sein Interesse gilt allem, was ITund Fachabteilungen flexibel und produktiv macht (Groovy, Drools, Scrum,Kanban, DevOps, fachliche Akzeptanztestverfahren).

1 www.objektspektrum.de

advertorial

Abb. 1: Einordnung von Softwaretests

Übungsaufgaben führt noch zu einer weite-ren Erkenntnis im Kontext der Software -entwicklung. Je länger der Zeitraum ist, indem eine Software entsteht und keine Testsvorliegen, desto schwieriger und teurerwird eine spätere Korrektur. Test-DrivenDevelopment (TDD) [Beck02] greift diesenPunkt auf. Beim TDD werden erst die Testsund dann die Software erstellt. Die beidenAnsätze CI und TDD haben allerdings denNachteil, dass die Testfälle nicht durch dieDomänenexperten selbst, sondern durchdie Softwareentwickler definiert werden.

Warum testen dieDomänenexperten selten?Übertragen auf die Metapher des Sprach -schülers bedeutet dieses Vorgehen, dass dieSchüler selbst die Übungsaufgaben definie-ren. Da sich das Erlernte aller Schülerergänzt, entstehen bessere Resultate, alswenn nur ein Schüler sich selbst testen wür-de. Sie ersetzen aber nicht die Tests derExperten, also der Lehrer.

Die späteren Nutzer einer Anwendungsind Experten in der Domäne und könnenam besten entscheiden, ob die umgesetztenAnforderungen in Form von Software kor-rekt umgesetzt wurden. Tests aus derAnwenderperspektive werden in der Regelallerdings erst sehr spät im Entwicklungs -zyklus einer Software definiert und zudemnur ein- bis zweimal ausgeführt. DiesePhase wird oft als Akzeptanz- oder Abnah -metest bezeichnet.

Warum erfolgt die Ausführung dieseroffensichtlich wertvollen Testfälle so spätund so selten? Zum Verständnis hilft es,sich die Tests etwas genauer anzusehen.

In den meisten Fällen handelt es sich beiden Testfällen um Checklisten, die vonDomänenexperten für Domänenexperten inderen Sprache erstellt und manuell durchge-führt werden. Diese manuellen Tätigkeitensind sehr aufwendig und passieren deshalbmöglichst selten. Erschwerend kommt ofthinzu, dass die Software den Experten erstrecht spät und „vollständig“ zum Test zurVerfügung gestellt wird.

Abbildung 1 zeigt die zwei Welten derSoftwaretests. Um kontinuierliches, quali-tativ hochwertiges Feedback für dieSoftwareentwicklung zu erhalten, müssteein Testvorgehen im Quadranten rechtsoben angesiedelt sein und die Inhalte derDomänenexperten sowie die Automati -sierungstechnologie zusammenbringen. Zudiesem Zweck müssen zum einen dieChecklisten strukturiert werden und zumanderen muss die Automatisierungs tech -nologie die Fachsprache übernehmen.

Checklisten strukturierenDie Checklisten der Domänenexpertenbestehen aus einzelnen Ausführungs- undPrüfschritten. Diese Schritte sind in derRegel in Form von Fließtext beschrieben:

n Lege ein leeres Wertpapierdepot ann Erwirb 20 deutsche Aktien zu je 2,00

Euron Verkaufe 10 Stück zu je 4,00 Euron Prüfe, ob sich noch 10 Stück im Depot

befindenn Prüfe, ob 20 Euro Gewinn entstanden

sind

Für einen Menschen, der über das entspre-chende Domänenwissen verfügt, ist diese Be -schreibung verständlich, für eine maschinelleAusführung jedoch zu wenig strukturiert.

Durch Methoden aus dem Behaviour-Driven Development [DanN] lässt sich dasBeispiel in einem ersten Schritt wie inAbbildung 2 strukturieren.

Damit gliedert sich die Beschreibung indrei Blöcke: „Eingangsdaten und Vorbe -dingungen“, „Ablauf“ und „erwartetesErgebnis“ beziehungsweise „Nachbedin -gung“. In allen drei Blöcken werden Be -griffe verwendet, die dem Domänen exper -ten geläufig sind und für die maschinelleAusführung näher definiert werden müs-sen. Bei den Begriffen handelt es sich zumeinen um Testdaten (wie leeres Wert -papierdepot, deutsche Aktie usw.) und zumanderen um Aktionen (wie Erwerben oderVeräußern).

TestdatenDamit ein Computerprogramm mit denTestfällen umgehen kann, müssen vorab dieEbenen Struktur (Syntax) und Inhalt(Semantik) dieser Daten definiert sein. Auf

2Online-Themenspecial Testing 2014

Online-Themenspecial Testing 2014 advertorial

Abb. 2: Strukturiertere Testfallbeschreibung

Abb. 3: Modelle für Testdaten

vier Parametern versehen: Depot, Aktie,Stücke und Kurs.

Damit die fachlichen Testfälle automati-siert ausgeführt werden können, definiertder Domänenexperte die notwendigenAktionen nach dem folgenden Schema:

n Name der Aktionn für jeden Parameter: Name und Schema

(Aktie, Wertpapierdepot, ...)

Der Umstand, dass die Parameter derAktionen fachlich „typisiert“ sind und alsTyp ausschließlich zuvor definierteSchemata verwendet werden können,ermöglicht eine strikte syntaktischeKonsistenzprüfung. Diese Prüfung ist füreine automatisierte Ausführung unerläss-lich. Die Software kann nur verarbeiten,was ihr vorab strukturiert bekannt ge -macht wurde.

Die Aktionsdefinitionen sind vergleich-bar mit Funktionsprototypen in C oder denMethoden eines Java Interfaces. Es handeltsich lediglich um die Signatur einerFunktion, deren Implementierung späterbehandelt wird. Für die Testdaten wurdejeweils der Bezug zu Konstrukten aus derobjektorientierten Programmierung herge-stellt. Um diese Analogie für die Aktionenfortzusetzen, würde der erste Parameteraus dem Beispiel ausgelassen und dieAktionen stattdessen „Methoden“ derAktie. Diese Art der Modellierung hat sichaber für die Domänenexperten als wenigerintuitiv herausgestellt, weshalb die eher„prozedurale“ Form beibehalten wurde.

TestfälleWenn die Testdatenvorlagen und die Ak -tionsdefinitionen vorliegen, könnte derDomänenexperte nach dem Baukasten -prinzip die konkreten Testfälle zusammen-stellen.

Der Ablauf des Testfalls (der ursprüng-lichen Checkliste) wird Schritt für Schrittaus den zur Verfügung stehenden Aktionenaufgebaut und mit den Testdatenvorlagenparametrisiert. Für das Beispiel sieht daswie folgt aus:

1. Wertpapierdepot anlegen (Privat kun -den depot)

2. Erwerben (Privatkundendepot, deut-sche Aktie, 20 Stück, 2 Euro/Stück)

3. Veräußern (Privatkundendepot, deut-sche Aktie, 10 Stück, 4 Euro/Stück)

4. Aktienbestand prüfen (Privatkun -dendepot, deutsche Aktie, 10 Stück)

Zur Verwendung der Testdaten in einemautomatisierten Test fehlen noch die eigent-lichen Inhalte. Für deren Festlegung bildendie Domänenexperten entsprechende Äqui-valenzklassen. Am Adjektiv „deutsche“ isterkennbar, dass im vorgestellten fiktivenBeispiel das Herkunftsland der Aktie eineAuswirkung auf die Abrechnung der bei-den Aktionen (Erwerb, Veräußerung)haben soll; für deutsche Aktien und US-Aktien sollen spezielle Abrechnungsver fah -ren gelten und für alle anderen einStandardverfahren.

Die Experten definieren „deutscheAktien“, „US-Aktien“ und „sonstigeAktien“ als Äquivalenzklassen. Alle übrigenHerkunftsländer werden in der Kategorie„sonstige Aktien“ zusammengefasst, da indiesen Fällen das konkrete Land keinenEinfluss auf die Testergebnisse hätte. Fürjede Äquivalenzklasse legt der Experte eineTestdatenvorlage an (siehe Tabelle 1).

Übertragen auf die objektorientiertenProgrammiersprachen sind die inhaltlichenÄquivalenzklassen mit Objekten - alsoInstanzen von Klassen - vergleichbar.

AktionenDie strukturierte Form der Testfall -beschreibung aus Abbildung 2 enthält diezwei Aktionen „Erwerben“ und „Ver -äußern“. Beide Aktionen sind mit jeweils

der semantischen Ebene wird das Prinzipder Äquivalenzklassen angewendet. AlsBeispiel soll die in der Checkliste verwen-dete „deutsche Aktie“ dienen.

Das Substantiv „Aktie“ ist der Einstieg indie strukturelle Beschreibung der Testdaten.Die Domänenexperten definieren, welcheDatenfelder im Bezug auf eine Aktie fürihren Test relevant sind. In diesem Beispielsollen alle Aktien-Testdaten gleich aufgebautsein und bilden somit das Schema vonAktien durch Festlegung in Form von „EineAktie besteht immer aus ...“:

n ISIN/ WKNn Namen Herkunftsland der Aktie

Sollte es im Hinblick auf den Test verschie-dene Arten von Aktien geben, bilden dieExperten entsprechende Äquivalenzklas-sen. So könnte es sein, dass Wert papier -depots von Privatpersonen und institutio-nellen Anlegern gemeinsame Merkmalebesitzen, aber auch jeweils Spezifika.

Die Strukturdefinition für Testdaten lässtsich mit der Definition von Klassen inobjektorientierten Programmiersprachen(oder bspw. struct in C) vergleichen. Dieverschiedenen Arten von Depots lassen sichüber einen Vererbungsmechanismus model-lieren (siehe Abbildung 3).

advertorial

3 www.objektspektrum.de

deutsche Aktie US-Aktie sonstige Aktie

ISIN DE000CBK1001 US0378331005 CH0038863350

WKN CBK100 865985 A0Q4DC

Name dt. Beispielaktie US-Beispielaktie sonst. Beispielaktie

Herkunftsland Bundesrepublik USA Schweiz

Deutschland

Tab. 1: Testdatenvorlagen für die drei Äquivalenzklassen

Abb. 4: Aufbau des fiktiven Softwaresystems

5. Gewinn prüfen (Privatkundendepot, 20Euro)

In den Schritten 4 und 5 ist zu sehen, dass dieDefinition und Prüfung von erwartetenErgebnissen (Struktur, Inhalte) analog zurDefinition der Testdaten erfolgt. Ebenso wirdmit der Anlage der Eingangsdaten verfahren.Allerdings hat das Erstellen von Testdaten -vorlagen aktuell eine sehr technische Form,die sich bei den Do mänenexperten in derpraktischen Nutzung nicht bewährt hat. ImFolgenden wird an einem durchgängigenBeispiel dargestellt, wie ein modellbasiertesTestwerkzeug zur Erstellung und Ausfüh -rung von Testfällen aussehen kann.

Fachsprache übernehmenIm ersten Schritt wurden die Checklisten ineine strukturierte Form überführt, die sichfür eine automatisierte Ausführung eignet.Bislang handelt es sich aber noch lediglichum eine Beschreibung der Testfälle. Imzweiten Schritt wird dieser BeschreibungLeben eingehaucht. Dieser Vorgang wirdanhand des in Abbildung 4 dargestelltenfiktiven Softwaresystems beschrieben;einem System zur Verarbeitung von Wert -papiergeschäften.

Das System hat eine datenbankbasierteLieferschnittstelle für die (Stamm-)Datender Wertpapiere und Webservice-Schnitt -stellen zum Anlegen von Wertpapierdepots,zum Tätigen von Geschäften sowie zurAbfrage von Beständen und Gewinnen.

TestdatenEin technisches Mapping bringt die Test -datenvorlagen und die Datenstrukturen derAnwendung zusammen.

Tabelle 2 ist ein Beispiel für ein solchesMapping zu entnehmen. Das Mapping lei-

tet die Informationen für einen gültigenDatensatz in der Eingangsdatenbank ausder Struktur der Aktie ab. Fixe Werte - wiefür den technischen Lieferstatus - oderkomplexere Mapping-Funktionen - wie zurAuflösung des Länderkürzels - sind eben-falls möglich. In der Regel entsteht zu die-sem Zweck eine passende domänenspezifi-sche Sprache (DSL).

AktionenDas Mapping der Daten bildet dieVorbereitung für den Schritt, den TestfällenLeben einzuhauchen. Die Ablaufbe schrei -bung des Testfalls ist aus einer Reihe von

Aktionen zusammengestellt, die bislangausschließlich Signaturen der „Funk -tionen“ sind. Für die Testausführung wer-den sie „implementiert“.

Im vorgestellten Beispiel bietet es sich an,nicht jede der Aktionen separat zu imple-mentieren, sondern über zwei beziehungs-weise drei generische Implementierungen:

n Schreiben in eine Datenbanktabellen Aufruf eines Webservice zum Schreiben

von Datenn Aufruf eines Webservice zum Lesen von

Daten

Die fachlichen Aktionsdefinitionen werdenmit diesen generischen Implementierungenüber eine Konfiguration verknüpft. Jederdieser Schritte beinhaltet die Ausführungdes Mappings.

Modellbasierter AnsatzDer vorgestellte Ansatz zur Definition fach-licher Akzeptanztests ist zunächst einmalnichts grundlegend Neues. BestehendeFrameworks wie Fitness [Fitn] oder Robot[Robo] basieren auf ähnlichen Prinzipien.Alle diese Frameworks benutzen allerdingseinen text- oder Skript-basierten Ansatz fürdie Erstellung von Testfällen. DieDomänenexperten müssen zum einen diepassende „Sprache“ erlernen. Zum ande-

4Online-Themenspecial Testing 2014

Online-Themenspecial Testing 2014 advertorial

Ziel Ausdruck

security_isin Aktie.ISIN

security_code Aktie.WKN

security_shortname Aktie.Name

security_country_code lookup(Aktie.Herkunftsland, COUNTRY_TABLE)

delivery_status 1

delivery_date NOW

Tab. 2: Beispiel für ein Testdaten-Mapping

Abb. 5: Pflegemaske für Testdaten

hohem Aufwand manuell aus, da ihnen diegängigen Automatisierungswerkzeugenicht eingängig genug sind und der Auf -wand zum Erlernen einer „neuen Sprache“zu fehleranfällig und zeitaufwendig ist.

Durch die Verwendung eines modellba-sierten Testansatzes erhalten die Expertenein Werkzeug, dem sie ihre eigeneDomänensprache „beibringen“ können; siemüssen keine fremde, technische Spracheerlernen, sondern können tool-gestütztTestfälle und -läufe definieren und ausfüh-ren. Gleichzeitig sind die Modelle imGegensatz zu den gängigen fachlichenTestbeschreibungen strukturiert. DieseEigenschaft erlaubt zum einen eineAutomatisierung der Tests. Zum anderenwird der fachliche Benutzer bei der Er -stellung von Testfällen unterstützt, sodasssyntaktische Fehler direkt vermieden wer-den können.

Cofinpro hat für einen Kunden aus derFinanzdienstleistungsbranche bereits einesolche Testplattform entwickelt, mit derTests für verschiedene Wertpapiersystemedurchgeführt werden. Hierbei zeigte sichzum einen der Nutzen der Automatisierungdurch schnelle Reproduzierbarkeit derTestergebnisse. Zum anderen stellte sichheraus, dass durch die Erstellung derTestdatenvorlagen auch eine Arbeitsteilungzwischen den verschiedenen Fachtesternmöglich ist. So entstanden Experten fürTeildomänen wie Kundenstammdaten,deren Testdatenvorlagen dann von ihrenKollegen verwendet werden können - ohne,dass sie über dasselbe Detailwissen verfü-gen. n

Da die Aktionsparameter typisiert sind,kann die Pflegemaske Falscheingaben ver-hindern. Es ist beispielsweise nicht mög-lich, eine Aktie an einer Stelle zu verwen-den, an der ein Wertpapierdepot sinnvollwäre.

FazitIn wenigen Projekten existieren automati-siert ausführbare fachliche Akzeptanztests,wodurch wertvolles Feedback für dieSoftwareentwickler verloren geht. DieDomänenexperten nutzen die Möglich -keiten der Testautomatisierung nicht, son-dern führen ihre Tests in der Regel mit

ren führen textbasierte Ansätze immer wie-der zu syntaktischen Fehlern in den Test -fallbeschreibungen.

Syntaktische Fehler lassen sich weitge-hend reduzieren, wenn die Erstellung derTestdaten, Aktionen und auch der Testfällekomplett modellbasiert erfolgt und diePflege über entsprechende Benutzermaskendurchgeführt wird.

In Abbildung 5 ist dieses Prinzip anhandder Pflegemaske für Testdaten dargestellt.Die Zeilen der Pflegetabelle werden aus derStruktur der Aktie abgeleitet. DerDomänen experte sieht alle relevantenAttribute. Beim Speichern wird überprüft,ob der Benutzer alle Attribute mit Wertenbelegt hat.

Noch deutlicher wird das Vorgehen ander Maske für die Erstellung von Testfällen(siehe Abbildung 6). Der Benutzer kann sei-nen Testfall aus einem fachlichen Bau -kasten system zusammenstellen. Auf der lin-ken Seite der Maske findet er alle zurVerfügung stehenden Aktionen und Test -daten. Der Testfall wird bequem imEntwurfsbereich in der Mitte per Drag&Drop zusammengestellt und konfiguriert.

advertorial

5 www.objektspektrum.de

Abb. 6: Pflegemaske für Testfälle

Literatur & Links

[Beck02] K. Beck, Test-Driven Development. ByExample, Addison-Wesley, 2002

[DanN] Dan North & Associates, Introducion BDD, siehe: http://dannorth.net/introducing-bdd/

[Fitn] http://www.fitnesse.org/

[Fowl06] http://www.martinfowler.com/articles/continuousIntegration.html

[Robo] http://robotframework.org/