Ganzheitliche Qualitätssicherung auf Basis von Modellen

Oder: Wie man einem Hamster das Bremsen beibringtModelle werden immer häufiger im Testumfeld genutzt, um Testfälle darzustellen und aus Test- oder Systemmodellen relevanteTestfälle abzuleiten – teils bereits automatisiert mit entsprechender Werkzeugunterstützung. Modellbasiertes Testen (MBT) isthier das Schlagwort. Es verheißt effizientes und effektives Testdesign und einen höheren Automatisierungsgrad im gesamtenTestprozess. Während man mit der Einführung modellbasierter Methoden oft insbesondere die Auswahl eines entsprechendenWerkzeugs und dessen Nutzung zur Erstellung und/oder Generierung von Testfällen auf Basis von Modellen verbindet, lässt sichder Bogen wesentlich weiter spannen. Der Einsatz von Modellen als allgemeines Mittel der Kommunikation und der Qualitäts -sicherung von Anforderungen, unabhängig von jeglichem Werkzeug zur automatisierten Testfallgenerierung, ist bereits ein mäch-tiges Instrument der analytischen Qualitätssicherung (QS) in frühen Entwicklungsphasen. Modelle sollten daher ein zentraler unddurchgängiger Bestandteil eines umfassenden Software-Entwicklungsprozesses sein – die Vision: eine ganzheitliche QS auf Basisvon Modellen.

So könnte sie aussehen, die heile Welt desTesters – wenn da nicht immer auch exter-ne Einflüsse wären, die permanent von

und gleichmäßigen Tempo: Teststufe fürTeststufe, Release für Release, Projekt fürProjekt…

Der Tester1) ist ein fleißiges Wesen: Er orga-nisiert und arbeitet auf Basis des funda-mentalen Testprozesses und stellt so einenreibungslosen Ablauf innerhalb seinesTestprojekts sicher:

■ Er entwirft initial seinen Testplan sowiesein Testkonzept und überwacht undsteuert den weiteren (Test-)Projekt -verlauf.

■ Er erstellt sein Testdesign und leitet dar-aus abstrakte und konkrete Testfälle ab.

■ Er führt seine Tests manuell oder auchteilweise automatisiert durch und hältTestergebnisse und Abweichungen fest.

■ Er verwaltet und klärt gefundene Ab -weichungen und berichtet regelmäßigüber den Testfortschritt und dieQualität der Software.

Dieses Testprozessrad durchläuft er konti-nuierlich, möglichst in einem kontrollierten

der au tor

Markus Nickolaus

(markus.nickolaus@logica.com)arbeitet seit Abschluss seines Studiums der Informatik an der TU Kaisers -lautern als Berater in großen Projekten mit den Schwerpunkten Anfor -derungs- und Testmanagement sowie Projektmanagement. Insbesondere fürdie Bereiche Testprozesse und -organisation ist er ein gefragter Experte undverantwortet bei der Logica Deutschland GmbH & Co. KG Themen wie modell-basiertes Testen. Er ist Mitautor der gleichnamigen iX-Studie.

1 www.objektspektrum.de

advertorial

1)Der Einfachheit halber wird hier auf eineUnterscheidung der verschiedenen Testrollen wieTestmanager, Testanalyst oder Testautomatisiererverzichtet.

Abb. 1: Der Tester im fundamentalen Testprozess(rad): Ein fleißiges Wesen, das gernesein Tempo selbst bestimmen würde und doch zumeist durch äußere Einflüsse ange-trieben wird.

außen am Prozessrad drehen, es unkontrol-liert beschleunigen oder ins Stocken gera-ten lassen. Die Planung gerät durcheinan-der, weil sich die Entwicklung verzögert. Jenäher man dem Testende kommt, destomehr Change Requests stehen plötzlich an.Unvollständige oder fehlerhafte Anfor -derun gen erfordern ein Redesign der Test -fälle; die Automatisierung muss wiederangepasst werden. Der Plan muss aufgrundder neuen Randbedingungen geändert wer-den, wohingegen der Inbetriebnahme -termin in Stein gemeißelt zu sein scheint.Die Probleme sind vielfältig und ließen sichbeliebig fortsetzen, und nicht selten drehtsich am Ende das Prozessrad so schnell und(aus Testsicht) unkontrolliert, dass derTester Mühe hat mitzukommen und auf-passen muss, dass er nicht „herausge-schleudert“ wird…

Das Ziel von MBT ist es, einige dieserProbleme zu entschärfen. MBT greift denGedanken einer durchgängigen Testauto -mati sierung auf und ermöglicht diesebereits in der Designphase des Test -prozesses. Aus Modellen heraus könnenumfangreiche Testszenarien und Testfällegeneriert werden, man erreicht eine höhereTestabdeckung und auf geänderte Anfor -derungen kann schneller reagiert werden.Die Suche nach Testfällen, die ggf. auf-grund von Change Requests angepasst wer-den müssen, entfällt zum großen Teil, daauf der Basis von geänderten Modellenwieder ein in sich konsistenter Satz an

Testfällen generiert werden kann. Die meis -ten MBT-Werkzeuge ermöglichen darüberhinaus eine automatisierte Testdurchfüh -rung, entweder bereits mit dem Werkzeugselbst oder durch eine geeignete Anbindungan existierende Automatisierungswerk -zeuge. Kurzum: Der Tester wird effektiver,effizienter und insbesondere flexibler. Unddamit lassen sich bereits einige äußereEinflüsse mildern – und die Geschwindig -keit des Testprozessrads wird etwas abge-bremst und besser kontrollierbar.

Wenn man sich allerdings auf Ursachen -forschung begibt, wird man feststellen,dass sich ein Großteil der Störfaktoren imTestprozess auf Probleme mit der Qualitätund/oder dem Management von Anfor -derun gen zurückführen lässt. VieleProbleme in späten Phasen des Entwick -lungs prozesses – und Testen steht nun ein-mal am relativen Ende der Prozesskette –lassen sich im weitesten Sinne auf mangeln-des Anforderungsmanagement zurückfüh-ren. Während man im Allgemeinen unterder Einführung von MBT insbesondere dieAuswahl eines entsprechenden Werkzeugsund dessen Nutzung zur effizientenErstellung und Generierung von Testfällenauf Basis von Modellen versteht, lässt sichder Bogen wesentlich weiter spannen. DerEinsatz von Modellen als allgemeinesMittel der Kommunikation und der Quali -tätssicherung von Anforderungen, unab-hängig von jeglichem Werkzeug zur auto-matisierten Testfallgenerierung, ist bereits

ein mächtiges Instrument der analytischenQS. Modelle sollten daher ein zentralerBestandteil eines umfassenden Software-Entwicklungsprozesses sein – und nicht nurdes Testprozesses. Wenn man an modellba-sierte Verfahren denkt, sollte es mithinnicht nur um die effiziente Verifikation derImplementierung am Ende des Ent -wicklungsprozesses gehen, sondern auchbereits um die Validierung der Anfor -derungen zu Beginn des Projekts. VonAnfang an können Modelle eingesetzt wer-den, um die Qualität der Anforderungen zusichern und zu steigern, beispielsweise feh-lende Sonderfälle zu erkennen und ergän-zen zu lassen. Im weiteren Verlauf desEntwicklungs- und Testprojekts unterstüt-zen modellbasierte Verfahren ein effizientesTestdesign, verhelfen in Verbindung miteinem passenden Testautomatisierungs-Framework zu einem nie dagewesenenTest automatisierungsgrad und ermöglichenin der Auswirkungsanalyse eine transpa-rente Darstellung von Fehlerwirkungenund deren Konsequenzen für einen mög-lichen Betrieb.

Die Vision ist eine ganzheitliche Quali -täts sicherung auf Basis von Modellen:modellbasierte Validierung der Anfor -derungen, automatisierte Verifikation derUmsetzung im gesamten Entwicklungs -prozess, einheitlich und effizient überAnwen dungsgrenzen hinweg.

1. Analysieren & Modellieren

Die systematische und strukturierte Um -setzung von fachlichen (zumeist immernoch Prosa-)Anforderungen in Modellebringt die Testanalysten bereits in einemfrühen „Entwicklungs“-Stadium dazu, sichintensiv mit den Anforderungen und demDesign zu befassen. Anforderungen werdenhinterfragt, ggf. dokumenten- und system-übergreifend auf Konsistenz geprüft undauf Modellierbarkeit, Vollständigkeit undTestbarkeit hin untersucht. Diese Phaseträgt dazu bei, dass die Anforderungenfrühzeitig qualitätsgesichert werden undreifen, was wiederum dem gesamten Ent -wicklungsprozess zu Gute kommt. Die frü-he Qualitätssicherung aus Test(mo -dell)sicht erlaubt es, Mängel oderMiss verständnisse in den Anforderungenzu identifizieren, bevor das Kind bei derEntwicklung bereits in den sprichwört-lichen Brunnen gefallen ist – und Problemein den Anforderungen sind bekannterma-ßen immer noch die häufigste Ursache fürdas Scheitern von Projekten.

2Online-Themenspecial Testing 2012

Online-Themenspecial Testing 2012 advertorial

Abb. 2: MBTX – Modellbasiertes Testen eXtended: eine ganzheitliche und umfassendeQualitätssicherung auf Basis von Modellen im gesamten Software-Lebenszyklus.

und verwaltet. Diese wird spätestens beider Durchführung der Tests im Rahmenvon Auswirkungsanalysen oder auch mitden nächsten Release-Zyklen benötigt, umÄnderungen an den übergeordneten fach-lichen Modellen gezielt und kontrolliert indie abgeleiteten technischen Modelle pro-pagieren zu können.

3. Automatisieren &

Durchführen

Insbesondere für die Phase Automatisieren& Durchführen ist es wichtig, ein MBT-Werkzeug einzusetzen, das sich nahtlos ineine (oder mehrere) existierende Testumge -bung(en) integriert. Es sollte auf der einenSeite eine vorhandene Testmanagement-Plattform unterstützen, was inzwischenviele der Werkzeuge standardmäßig tun.Andererseits sollte das Werkzeug der Wahlaber auch in vorhandene Testautomati -sierungsumgebungen integriert werdenkönnen. Hierbei kann es durchaus erfor-derlich sein, je nach Teststufe auch unter-schiedliche Automatisierungslösungen zuunterstützen, beispielsweise von JUnit fürentwicklungsnahe Komponenten- undUnit-Tests bis hin zur Anbindung an Werk -zeuge wie Quicktest Pro oder BusinessProcess Testing von HP. Je vielfältiger dieIntegrationsmöglichkeiten in vorhandeneTestautomatisierungsumgebungen bzw.den Zieltestrahmen sind, desto größer wirdder Ende-zu-Ende-Automatisierungsgradim gesamten Testprozess. Eine Werk -zeugkette, in der zwischen generiertenTestskripten und der eigentlichen Lauf -fähigkeit in der Zielumgebung noch größe-re manuelle Aktivitäten liegen, baut zusätz-liche Fehlerquellen in den Prozess ein.

Trifft eine solche modellbasiert generier-te Testautomatisierung auf ein entspre-chend vorbereitetes Automatisierungs-Frame work, so kann tatsächlich einedurchgängige Testautomatisierungsstreckevon der Testfallgenerierung bis hin zurTestdurchführung erreicht werden – unddas nicht nur im Bereich von Akzeptanz -tests, sondern z. B. auch als integraler Bestand teil eines kontinuierlichen Integra -tions prozesses in Form von in die Ent -wicklungsprozesse eingebundenen Kompo -nen ten- oder Integrationstests im Rahmenvon Nightly Builds.

Entscheidend ist das Miteinander derjeweiligen Werkzeuge bzw. Umgebungen,und dies ist nur teilweise eine Frage dertechnischen Schnittstellen. Mehr noch isteine enge Abstimmung und Zusammen -

Das deutlich höhere Abstraktionsniveaubei der Definition von Test- und/oderSystemmodellen und die intelligenten Ver -fahren, mit denen sich aus diesen Modellendann auch automatisiert ausführbareTestfälle generieren lassen, ermöglicheneine enorme Steigerung der Effizienz bereitsin der Testdesignphase im Vergleich zurmanuellen Testfallerstellung. Dies ist insbe-sondere die Domäne der MBT-Werkzeuge.

Hierzu müssen die fachlichen Modelleerweitert und konkretisiert werden – bei-spielsweise durch die Definition undAuswahl von Testdaten. Es kann aber auchdurchaus sinnvoll oder sogar notwendigsein, weitere detailliertere Modelle abzulei-ten, wie die folgenden Szenarien zeigen:

■ Die existierenden Modelle bilden über-greifende Geschäftsprozesse über eineganze Systemlandschaft hinweg ab: Indiesem Fall müssen diese Prozesse bzw.Modelle auf die jeweiligen Einzel -systeme heruntergebrochen werden.Einem finalen Abnahmetest der gesam-ten Systemlandschaft können dann bei-spielsweise modellgetriebene System-und Abnahmetests der Einzelsystemevorangestellt werden.

■ Die existierenden Modelle beschreibendie fachlichen Abnahmeszenarien:Frühere Teststufen bis hin zur Ein -bettung von Testszenarien in einen kon-tinuierlichen Integrationsprozess derEntwicklung sollen ebenfalls unter-stützt werden und erfordern einen tiefe-ren Systemeinblick. Detailliertere Mo -delle können teststufenspezifischabge leitet und erstellt werden, um bei-spielsweise nahtlos in unterschiedlicheAutomatisierungsumgebungen inte-griert werden zu können.

■ Die existierenden Modelle dienten bis-her der Kommunikation mit dem Fach -bereich: Um in einem vorhandenenTestautomatisierungs-Framework ausden Modellen unmittelbar lauffähigeTestskripts generieren zu können, musseine Anpassung an die Bedürfnisse desTestrahmens erfolgen. Beispielsweisesollten vorhandene (automatisierte)Aktionswörter in den Modellen genutztund entsprechend parametrisiert wer-den.

Bei all diesen Modellierungsaktivitäten istdarauf zu achten, dass man eine Rück -verfolgbarkeit in das übergeordnete Modellbis zu den Anforderungen im Auge behält

Unter Modellieren sei hier eine systema-tische und strukturierte (nicht notwendi-gerweise grafische) Darstellung vonSystem verhalten, Abläufen, Entscheidun -gen oder auch Daten verstanden. Dies kanndurch „tabellarische Modelle“ wie Ent -scheidungstabellen oder auch durchKlassifikationsbäume für die Struktu -rierung von Datenräumen erfolgen. MitMBT werden zumeist grafische Modell -arten wie UM-Aktivitäts- oder Statusüber -gangs diagramme verbunden. Aber auchaus einer simplen Entscheidungstabelle las-sen sich im weiteren Projektverlauf auto-matisiert Testfälle ableiten. Nach dieserPhase sollte man aus den modelliertenArtefakten bereits einen großen Satz anTestanforderungen und späteren Akzep -tanzkriterien ableiten bzw. werkzeugge-stützt generieren können.

Man sollte sich im Vorfeld mit derFachseite und/oder den Business-Analystenauf einige wenige Modellarten einigen. DerSchwerpunkt bei der Auswahl sollte hiernoch nicht unbedingt auf der anschließen-den Testfallgenerierung liegen: Entschei -dend in dieser frühen Phase ist dieMöglichkeit, auf Basis dieser Modelle mitder Fachseite kommunizieren zu können.Ein noch so umfassendes und vollständigesSystem- oder Testmodell hilft nicht, wenndas Gegenüber dieses nicht halbwegs eigen-ständig lesen und prüfen kann (oder dies imFalle mangelnder Akzeptanz auch gar nichtwill). Bei verteilten oder ausgelagertenEntwicklungsorganisationen kann es sogarsinnvoll sein, den Abschluss einer solchenQualitätssicherungsphase auf den Anfor -derungsdokumenten im Sinne eines QualityGates vor die Übergabe der Pflichtenheftean die jeweiligen Entwicklungsteams zustellen.

2. Konkretisieren & Generieren

Nach der Phase Analysieren & Modellierenliegen eine Reihe fachlicher Modelle vor,aus denen sich bereits entsprechende Test -szenarien ableiten lassen. Man hat dieAnforderungen qualitätsgesichert, mit demFachbereich bereits einen großen Satz anAkzeptanzkriterien und -tests vereinbartund somit beidseitig die Grundlage und dasVerständnis für einen späteren, gemeinsa-men Abnahmetest gelegt. In der anschlie-ßenden Phase muss nun ein umfassendesTestdesign erfolgen: Konkrete Testfällemüssen erstellt werden, und man will soviel wie möglich mit einer entsprechendenWerkzeugunterstützung automatisieren.

advertorial

3 www.objektspektrum.de

arbeit zwischen dem Modellierungs- unddem Testautomatisierungsteam der Garantfür einen optimalen Testautomati sierungs -grad. In einer Schlüsselwort-getriebenenAutomatisierungsumgebung liefert bei-spielsweise der vorhandene Satz anSchlüsselwörtern eine Basis für die Akti -vitäten oder Statusübergänge, die auch imModell verwendet werden sollten. Und imRahmen der Weiterentwicklung gibt dasModellierungsteam vor, welche neuenSchlüsselwörter automatisiert bzw. welcheexistierenden Schlüsselwörter aufgrundvon geänderten Anforderungen überarbei-tet werden müssen. Die Effektivität derTestautomatisierungsstrecke wird durchdie Werkzeuge und den erzielten Inte -grationsgrad definiert. Die tatsächlicheEffizienz wird jedoch von gut aufeinanderabgestimmten Prozessen und miteinanderarbeitenden Teams gesteuert.

4. Bewerten & Berichten

Am Ende des Tages geht es nicht nur umdie Ausführung von möglichst vielen Testsund das Finden von Fehlern, sondern auchum deren Beurteilung. Welche (fachlichen)Auswirkungen hat ein gefundener Fehler?Kann man damit in Betrieb gehen odermuss er erst behoben werden? VerfügbareModelle helfen bei solchen Fragestellun -gen, und einige Werkzeuge sind in derLage, aufgetretene Fehler im Anschluss andie Testdurchführung auch wieder imModell zu visualisieren: Welcher Pfad warbetroffen? Ist dies ein Sonderfall oder blo -ckiert dies den gesamten Geschäftsprozess?Habe ich alternative Pfade, mit denen ichtrotzdem erst einmal in Betrieb gehen

kann? Derartige modellbasierte Visuali -sierungen unterstützen die Lokalisierungund Bewertung von Problemen, um damitz. B. auch mit einem Fachbereich überKonsequenzen diskutieren zu können.Zusätzlich unterstützen Modelle auchquantifizierte Aussagen zum Grad der bisdato erzielten Testabdeckung auf Basis derverschiedenen Überdeckungsgrade, die aufihnen definiert werden können.

Und hier schließt sich dann auch wiederdie Prozesskette zum nächsten Release-Zyklus: Die Modelle der jeweiligen Phasendes abgeschlossenen Releases werden zurAusgangsbasis für das Folge-Release. Dieneuen oder geänderten Anforderungenwerden in der Phase Analysieren &Modellieren in die existierenden Modelleeingebracht; neue Modelle entstehen. DieseÄnderungen werden in die spezifischen undkonkreten Modelle aus der Phase Konkre -tisieren & Generieren propagiert, um dannerneut als Grundlage für die Generierungder Testautomatisierungsbasis zu dienen…Wenn man dieser Prozesskette ausAbbildung 2 folgt, so erinnert das an dasmathematische Unendlichkeitszeichen (∞):ein ewiger Kreislauf. Das Testprozessraddreht sich von Teststufe zu Teststufe, vonRelease zu Release, von Projekt zu Projekt.

Fazit

Modelle und Qualitätssicherung bildeneine natürliche Symbiose. Sie sind starkeVerbündete beim steten Versuch, dieQualität der Anforderungen so frühzeitigwie möglich zu erhöhen und so einen dergrößten Risikofaktoren in Projekten zu ent-schärfen. Je früher und je konsequenter

Modelle eingesetzt werden, desto größer istder zu erwartende Mehrwert im Projekt.Mit entsprechender Werkzeugunterstüt -zung gelingt der Aufbau einer durchgängi-gen modellbasierten Automatisierungs -strecke vom Testdesign bis zurTest durchführung, und in Modellen kön-nen die Auswirkungen von Fehlern trans-parent und verständlich gemacht werden.

Entscheidend für einen funktionierendenund effizienten Testprozess sind jedoch diedurchgängige Berücksichtigung von Mo del -len im gesamten Software-Entwick lungs -prozess und eine entsprechende Verzah nungder einzelnen Prozessschritte. Ohne aufein-ander abgestimmte Einzel prozesse undeinen integrativen Ansatz erhält man –wenngleich auch effiziente – isolierteTestinseln, verschenkt aber das vorhandenePotenzial einer umfassenden Qualitäts -sicherung. Nicht die einzelnen eingesetztenWerkzeuge an sich sind wichtig. Vielmehrermöglicht es erst ihr nahtloses Miteinanderin einem abgestimmten Gesamtprozess, dengesamten Mehrwert auszuschöpfen. Dierichtige Einführung modellbasierterMethoden und unterstützender Werkzeugeist zuallererst eine Frage der konsistentenund übergreifenden Prozessdefinition, derErstellung eines (modellbasierten) Zielfotosfür den gesamten Softwareentwick lungs -prozess. Erst diese Vision einer ganzheit-lichen Qualitäts sicherung auf Basis vonModellen – einhergehend mit einer konse-quent darauf ausgerichteten, integrativenWerkzeug unter stützung – ermöglicht esdem Tester, das Tempo in seinem Test -prozessrad kontrolliert zu drosseln und sei-ne Lauf geschwindigkeit mehr und mehrwieder selbst zu bestimmen. ■

4Online-Themenspecial Testing 2012

Online-Themenspecial Testing 2012 advertorial

Abb. 3: Je besser sich ein MBT-Werkzeug in vorhandene Testautomatisierungs lösungen integrieren lässt, desto vielfältiger sind dieEinsatzmöglichkeiten in den unterschiedlichen Teststufen und -phasen.