Links und rechts des Weges: Qualitäts-sicherung ist mehr als Testfallverwaltung Testen ist Teil eines komplexen Prozesses auf dem Weg von einer Idee oder einem Problem zu einer fertigen Software. Testen hatdie Aufgabe, die Qualität der und das Vertrauen in die auszuliefernde Software sicherzustellen. Dabei kommen verschiedeneTesttechniken und -methoden zum Einsatz: funktionale Tests, Beta- und Alpha-Tests, Akzeptanztests sowie entwicklernaheTesttechniken, wie Unit- und Integrationstests sind nur einige Beispiele.

Kundenproblem oder eine Anfor derung.Diese unkonkreten „Kunden wünsche“werden anschließend durch einen formalenAnforderungsmanagement-Prozess struk-turiert aufbereitet. Je nach Vorgehens -modell heißen die entstehenden Artefaktedann Anforderungen bzw. User Stories. DieTechniken zur Erfassung, Verarbeitung undTransformation dieser Kundenwünschestellen hier nicht den inhaltlichen Fokusdar (weiterführende Informationen siehe[Sig-2]).

Aus unserer Sicht gibt es in vielen Pro -jekten an der Schnittstelle zwischen Testenund Anforderungsmanagement die folgen-den Ursachen für hohe Abstimmungs -aufwände oder geringe Zusammenarbeit:

■ Medienbrüche: Verwendung von ge -trennten Informationssystemen entlangdes gesamten Entwicklungs prozesses:So verwendet z. B. das Produkt -management Word-Dokumente, dieEntwicklung SVN und die Tester HPQC für die Testverwaltung sowieBugzilla für die Fehlererfassung undKommunikation mit der Entwicklung.Das sorgt für Informationsverlust anjeder Schnittstelle.

■ Unklare Verhältnisse: Reviews werdenselten durch wichtige Interessens ver -treter (Stakeholder) durchgeführt. Die

In den folgenden Abschnitten möchten wirSie auf eine Reise durch die verschiedenenBereiche eines Software-Lifecycles mitneh-men und Ihnen dabei neue Ideen links undrechts des Weges zur Verbesserung derQualität Ihrer Software außerhalb der „klas-sischen“ Testfallverwaltung und Aus führungvon Testfällen aufzeigen. Im Detail werdendabei exemplarisch Maßnahmen für dieSoftware-Lifecycle-Phasen „Spezifi zieren“,„Planen“, „Umsetzen“, „Testen“ und„Ausliefern“ betrachtet (siehe Abbil dung 1).

Die Basis für alles:

Anforderungen

Den Beginn einer jeden Software-Ent wick -lung markiert ein allgemein formuliertes

Als Technologie- und Prozessberater füreffizientere Software-Entwicklung bei AIThaben wir häufig die Gelegenheit, dieSoftware-Entwicklungsprozesse in ver -schie denen Unternehmen zu analysieren.Ein Muster lässt sich dabei sowohl bei agil(z. B. Scrum) als auch bei traditionell (z. B.Wasserfallmodell) orientierten Arbeits wei -sen beobachten. Viele Teams sind geprägtvon einer strikten organisatorischen undthematischen Isolation von Testern undEntwicklern. Qualitätssicherung als Begriffist in diesen Teams im Wesentlichen mit(manuellem) Testen gleichgesetzt (vgl.[Cha-1]). Der gelebte Prozess läuft meistnach einem ähnlichen Schema ab: zuBeginn Definition von Testfällen, dann(manuelle) Ausführung von Testfällen,Meldung von Fehlern an die Entwicklung,Nachtesten von Fehlerbehebungen undzum Abschluss Freigabe der Software.

Die Folgen dieser einseitigen Betrachtungvon Qualitätssicherung als „nur Testen“sind immens. Es entstehen hohe Test -aufwände bei geringer Qualität, verzögerteFreigabetermine aufgrund zu spät durchge-führter Qualitätssicherungsmaßnahmenund besonders schwerwiegend: isolierteund demotivierte Teammitglieder im ge -samten Produktteam. Die Ursache: Quali -tätssicherung wurde nicht als gemeinsameübergreifende Aufgabe wahrgenommen.

der au tor

Nico Orschel

(nico.orschel@aitgmbh.de)ist MVP (Microsoft Most Valuable Professional), ISTQB-zertifizierter Software-Tester und Berater des AIT TeamSystemPro-Teams. Er hat sich u. a. auf dasautomatische Testen mit dem Visual Studio Lab Management spezialisiert. Erberät Unternehmen bei der Einführung und Anpassung des Visual StudioTeam Foundation Server. Seine Erfahrungen vermittelt er zudem als Autordes TFS-Blogs, in Magazinen und in Vorträgen.

1 www.objektspektrum.de

advertorial

Abb. 1: Software-Lifecycle.

Interessensvertreter sind gegensätz-licher Meinung und Ansicht und es istnicht geklärt, wer in letzter Instanz ent-scheidet. Das sorgt für fehlende Klar -heit und häufiges Verfehlen der Er war -tungen.

■ Fehlende Informationen: Entschei dun -gen und Review-Ergebnisse sind nichtdokumentiert oder stehen aufgrundunterschiedlicher Werkzeuge nicht zen-tralisiert für alle zur Verfügung.

Eine Möglichkeit, diese Probleme anzuge-hen, ist die Nutzung einer integriertenALM-Plattform. Solche Plattformen dek-ken dabei verschiedene ALM-Bereiche wieSoftware-Lifecycle-Management, Betrieb(Operations) und Verwaltung (Gover nance)ab (Definition von ALM siehe [Cha-2]). Fürdie Entwicklungsprojekte mit unserenKunden setzen wir dabei seit mehrerenJahren erfolgreich auf den Team Foun -dation Server (TFS) aus dem Hause Micro -soft. Für die Phase „Anforderungs -management“ ermöglicht der TFS über sogenannte „Work Items“ die einfacheErfassung und Verwaltung von Anfor -derungen oder User Stories. Über den glei-

chen Mechanismus werden auch Testfälle,Feedback und Reviews (inkl. Ergebnisse) inden späteren Phasen unterstützt. In Ab -hängigkeit vom jeweiligen Artefakttyp(„Anforderung“, „Review“, „Feedback“)können die Felder und Regeln sowie derWork flow variieren. Die jeweiligen Ele -mente sind keine geschlossenen Systeme,sondern können im laufenden Projekt andie jeweiligen Bedürfnisse angepasst wer-den. In Abbildung 2 ist beispielhaft dieErfassung einer Anforderung in VisualStudio dargestellt. Neben Visual Studiokönnen Sie als Anwender auch andereWerk zeuge gleichberechtigt verwenden.Beispiele sind z. B. Webzugriff perWebAccess, Excel, Project, Visual Studio,Microsoft Testmanager (MTM), AITWordToTFS (siehe [Ait]) oder TeamCom -panion für Outlook. Der große Vorteilbesteht darin, dass je nach Rolle der Team -mitglieder bereits etablierte Werkzeuge fürden Zugriff auf die gemeinsamen Artefaktewie Anforderungen, Fehler oder Feedbackgenutzt werden können. Durch die zentraleSpeicherung aller Informationen im TFShaben alle Teammitglieder die Möglichkeit,zu jeder Zeit Rückmel dun gen/Ver bes -

serungsvorschläge zu allen Artefakten(hier: Anforderungen) zu geben. Die erhöh-te Transparenz sorgt als positiver Effektdafür, dass Inkonsistenzen, Lücken undWidersprüche bereits frühzeitig erkanntund behoben werden.

Ein Beispiel für einen gelebten Prozess ausunserem Projektalltag ist die Nutzung vonWord und TFS für die Anfor derungs -definition. In der Spezifikationsphase setzenwir primär auf Word mit WordToTFS, unse-re kostenlosen Erweiterung für Word undTFS. WordToTFS ermöglicht die einfacheund schnelle Aufnahme, Bearbeitung undSynchronisierung von Work Items zwischenWord und dem TFS (siehe Abbildung 3). DieSynchronisierung kann dabei sowohl vonWord nach TFS als auch von TFS nach Wordstattfinden. Der Einsatz von Word hat dabeimehrere praktische Vorteile: Erstens kanndas Anforderungsdokument sehr einfach alsVertragsbestandteil verwendet werden, zwei-tens können Kunden auch ohne TFS-Zugriffproblemlos Anforderungen prüfen undanpassen und drittens steht allen Beteiligtender aktuelle Stand im TFS zur Verfügung.

Im nächsten Schritt („Planen“) werdenaus den hinterlegten Anforderungen diejeweiligen Aufgaben für alle Teammit -glieder erstellt, geplant und mit den betrof-fenen Anforderungen verknüpft. Hier führtebenfalls wieder Transparenz zur frühzeiti-gen Vermeidung von Fehlern und Miss -verständnissen.

Mit Ausblick auf den neuen TFS 2012sollen zwei neue Programme für die frühenEntwicklungsphasen nicht unerwähnt blei-ben: Feedback-Client und PowerPoint-Storyboarding.

Der Feedback-Client ermöglicht dieAufzeichnung von Feedback durch Stake -

2Online-Themenspecial Testing 2012

Online-Themenspecial Testing 2012 advertorial

Abb. 2: Anforderungen aufnehmen mit Visual Studio.

Abb. 3: Anforderungen aufnehmen mit WordToTFS. Abb. 4: Feedback an Entwicklung geben.

steht als großer Schritt deren Umsetzungan. Auch hier gibt es oft Stellen, an denenes zwischen Testern und Entwicklern häu-fig zu Problemen kommt:

■ Fehlende Nachverfolgbarkeit vonQuell code zu anderen Projekt arte fak -ten (z. B. Anforderungen/Aufgaben).

■ Stand der Umsetzung ist für Nicht-Entwickler nicht transparent.

■ Übergabe von halbfertigen Funktionenan andere Interessengruppen (z. B. Tes -ter).

■ Integration von Teillieferungen inner-halb der Entwicklung erfolgt zu spätfür Tests.

Auch für den Bereich Quellcodeverwaltungsetzen wir bei AIT den TFS als Plattform ein.Der TFS bietet die Möglichkeit, an einenEincheck-Vorgang bestimmte Bedin gungenzu stellen (Check-In Policies), welche vorjedem Check-In von Änderungen erfüllt seinmüssen. Über diese Regeln kann man z. B.den Entwickler erinnern, bei jedemEincheck-Vorgang die bearbeitete Anfor -derung zu verknüpfen, um eine Nach -verfolgung zwischen Code und An for derung(siehe Abbildung 6) zu ermöglichen.

Der TFS bietet die Möglichkeit, diverseArtefakte miteinander zu verknüpfen,sodass ein umfangreiches Beziehungs -geflecht der verschiedenen Artefakte wie inAbbildung 5 entsteht. Auf Basis dieserInformationen hat der Tester jetzt Mög -lichkeiten, den Stand einer Umsetzung bzw.Fehlerbehebung einzusehen oder die Ver -knüpfung zur Durchführung von Auswir -kungsanalysen z. B. zwischen Code undAnforderungen oder Code und Testfällenzu verwenden. Ein häufiger Anwendungs -fall ist die Ermittlung, ob ein Featurebereits fertig gestellt wurde und in welchesRelease es integriert wurde. In Abbildung 7

holder. Das Programm leitet den Anwenderdurch einen einfachen Prozess, bei demScreenshots oder eine Videoaufzeichnungerzeugt werden, während der Anwenderdie Testversion einer Software oderWebseite prüft – ein Bild sagt schließlichmehr als 1000 Worte (siehe Abbildung 4).Das Feedback wird direkt im TFS gespei-chert und kann Grundlage für die Ände-rung von Anforderungen sein.

Das PowerPoint-Storyboarding als weite-res Instrument ermöglicht die Erstellung vonUI-Prototypen mit PowerPoint (sieheAbbildung 5). Durch Verwendung vonPowerPoint als Standardwerkzeug könnenmit sehr wenig Lernaufwand und ohne Codefrühzeitig Prototypen eines Pro grammserstellt werden. Auf Grundlage dieser Proto -typen können Rückmeldungen von wichti-gen Entscheidungsträgern oder Kunden ein-geholt werden, noch bevor die Entwicklungin die falsche Richtung startet. Die erstelltenStoryboards wiederum werden zentral abge-legt und mit den Anforderungen im TFS ver-knüpft. Sie stehen damit für die spätereVerwendung neben den Anforderungen zumbesseren Verständnis zur Verfügung.

Nachverfolgung von

Anforderungen

Nachdem die Anforderungen an das Pro -dukt definiert und Aufgaben geplant sind,

advertorial

3 www.objektspektrum.de

Abb. 5: Storyboarding mit PowerPoint.

Abb. 6: TFS-Beziehungsmodell.

sehen Sie ein Beispiel für genau dieseNachverfolgung von einer Anforderung zueinem speziellen Build. Durch den Statusder Anforderung ist der Stand derUmsetzung ebenfalls ableitbar. Zusätzlichkann der Entwickler nach Fertigstellungeines Features die Aufgabe ohne Medien -bruch an den Tester weiterreichen.

Strukturierung der

Quellcodeverwaltung

Im Themenbereich der Quellcode ver -waltung gibt es noch einen weiteren großenBereich, welcher die Tester direkt betrifft:die Struktur der Entwicklungszweige(Branches). Jetzt stellt sich sofort die Frage:Wo besteht der Zusammenhang zwischenBranching und Testen? In vielen bestehen-den Projekten findet man sehr oft eineStruktur wie in Abbildung 9 dargestellt.Diese Struktur ist gekennzeichnet durcheine Hauptentwicklungslinie („main“)sowie einen oder mehrere „release“-Zweigefür die veröffentlichten Versionen. Jederdieser Entwicklungszweige ist ein in sichkonsistenter Container mit allen zusam -men gehörigen Produktartefakten (Quell -code, Tests, Bibliotheken, Build-Skripts,Dokumentation etc.). Auf der genanntenHauptentwicklungslinie arbeiten dabeisowohl Entwickler als auch Tester.Entwickler setzen fortlaufend neue Fea -tures um und checken diese direkt in denHauptzweig ein. Die Tester wiederumbedienen sich zum Testen jeweils einerSoftware-Version aus diesem Zweig. Mankann daraus schlussfolgern, dass dieQuellcodeverwaltung eine direkte Schnitt -stelle zwischen Entwicklung und Tester undentsprechend kritisch für die Arbeit vonbeiden Parteien ist. Das aktuelle Vorgehenmit „main“- und „release“-Zweigen hatauf den ersten Blick den Charme, dass essehr leichtgewichtig scheint und Mehr -

Abb. 7: Nachverfolgung von Anforderungen zu Builds.

arbeit verhindert. Auf den zweiten Blickaber offenbaren sich in vielen alltäglichenSituationen jedoch Schwächen. In einigenProjekten beobachtet man die Situation,dass an Tester öfter unfertige Featuresübergeben werden und anschließend eineWelle von „unnötigen“ Fehlermeldungenan die Entwicklung gemeldet wird. Diese„unnötigen“ Fehlermeldungen sorgen alsFolge dann für unnötige Mehrarbeit unddamit Demotivation auf beiden Seiten.

Das beschriebene Problem lässt sichdabei mit einem überschaubaren Einsatzdurch eine angepasste Branching-Strukturadressieren. In der Praxis gibt es je nachSituation verschiedene Strategien (vgl.[Vsa]). In Abbildung 10 wurde dazu alsErweiterung ein zusätzlicher Entwick lungs -zweig („dev“-Branch) eingeführt. DieWeiterentwicklung neuer Features wirdnun immer zuerst auf diesem Zweig erfol-gen. Ist ein Feature vollständig implemen-tiert und es erfüllt zuvor festgelegteQualitätsanforderungen (Quality Gates),dann werden die Änderungen vom „dev“-Zweig nach „main“ integriert. Beispiele fürzuvor genannte Quality Gates sind:

■ Kompilieren des Quellcodestands istmöglich.

■ Statische Code-Analyse wurde ausge-führt und Regelverletzungen befindensich im tolerierten Bereich, d. h. derQuellcode wurde automatisch aufCode-Konventionen geprüft und ent-spricht damit den internen (Projekt-)Vorgaben.

■ Unit- und Integrationstests sind erfolg-reich ausgeführt worden.

Als Ergebnis der durchgeführten An pas -sung enthält der „main“-Zweig nur nochstabile Versionen und damit testbareFeatures. Als Tester verwendet man jetztnicht mehr „halbfertige“ Versionen ausdem „dev“-Zweig, sondern nur stabile ausdem „main“-Zweig, sodass „unnötige“Fehlermeldungen und Blockaden seitensder Entwickler vermieden werden.

Automatisches Erstellen

der Software

Zu guter Letzt verbleibt noch ein Punkt mitviel Diskussionsstoff: automatisiertesKompi lieren und Prüfen der Software mit -tels eines Build-Prozesses. Werden Ver -sions stände der Software nicht automati-siert, sondern manuell und auf einem„bestimmten Entwickler-PC“ ausgeführt,dann ergeben sich folgende Risiken:

■ Kompilieren ist nur mit komplexemSetup auf einem Entwickler-Rechnermöglich und damit fehleranfällig undaufwändig.

■ Wissen über die Release-Erzeugungsteckt in wenigen Köpfen und ist inaller Regel nicht dokumentiert.

■ Prüfung, ob abhängige Produkte nochfunktionieren, erfolgt sehr spät (Inte -grationsfehler).

■ Integration von nicht autorisiertenSoft ware-Versionen verursacht Fehlerbei Kunden und beim Testen.

■ Statische und dynamische Tests werdenaus Zeitgründen nicht ausgeführt(Unit-Tests, statische Code-Analysenetc.).

Auch zur Abbildung von Build-Prozessensetzen wir auf die in den TFS integrierteBuild-Plattform. Der TFS unterscheidetzwischen fünf Build-Typen: „ContinuousIntegration“, „Rolling Builds“, „GatedCheck-In Builds“, „Scheduled Builds“ und„Manuell gestartete Builds“. Die Kunstbesteht jetzt darin, diese verschiedenenBuild-Typen in Abhängigkeit von der jewei-ligen Entwicklungslinie und Zielstellungeinzurichten. Nicht jeder Build-Typ ist fürjede Situation geeignet. Die richtigeMischung zwischen Branch- und Build-Typhingegen kann statt Mehrarbeit dieQualität ihrer Releases signifikant steigern.Mehrarbeit wird reduziert, weil auch hiersehr früh automatisch Feedback an dieEntwickler gegeben wird. Neben derFunktion als Feedback-Instrument bildenBuild-Prozesse zudem eine unabhängigePrüfinstanz zwischen den verschiedenenEntwicklungszweigen bzw. -phasen.

Eine Empfehlung aus unserem Projekt -alltag ist der Einsatz von ContinuousIntegration Builds (CIBs) auf derEntwicklungslinie für schnelles Feedback.Dabei löst jeder Check-In automatisch denBuild der Software aus. Der Vorteil bestehtdarin, dass jede Änderung geprüft wird undFehler auf Ebene des einzelnen Check-Ins

4Online-Themenspecial Testing 2012

Online-Themenspecial Testing 2012 advertorial

Abb. 8: Verknüpfung von Anforderungen und Changesets.

Abb. 9: Einfache Branching-Struktur. Abb. 10: Basis-Branching-Struktur.

Integriertes Testmanagement

Nachdem die Software erfolgreich erstelltwurde, kann diese an die Tester übergebenwerden. In dieser Phase bietet es sich an,den Microsoft Test Manager als integriertesWerkzeug für Testmanagement- und Test -ausführungsaufgaben mit dem TFS einzu-setzen. Vorteilhaft sind hier die tiefeIntegration mit dem TFS und dadurchVermeidung von Medienbrüchen mit denSystemen der Entwicklung. ImVorgängerartikel (siehe [Sig-1]) wird detail-liert auf diesen Testprozess mit MTM unddie Optimierung der Kommunikation mitEntwicklern eingegangen.

Fazit

Wir haben Ihnen im Artikel gleich mehrereIdeen zur ganzheitlichen Steigerung derQualität Ihrer Entwicklung aufgezeigt. DieseIdeen sind dabei bewusst nicht aufTestfallverwaltung und -ausführung be -schränkt. Der Fokus der Verbesserungs maß -nahmen liegt schwerpunktmäßig bei Aktivi -täten an den Schnittstellen Tester/Entwickler,Tester/Produkt manage ment und Tester/Kunde. Als konkrete Maßnahme wurdegezeigt, dass ein integriertes System dabeihelfen kann, frühzeitig Fehler bereits in derAnforderungs definitionsphase zu finden.Dies ist möglich, weil alle Anwendergruppeneinen „einheitlichen“ Zugriff auf alleInforma tionen der Entwicklung haben – die„einzige Wahrheit“ des Projekts. Beispielesind z. B. Anforderungen, Aufgaben, Test -fälle oder Prototypen.

Zusammenfassend kann gesagt werden,dass Qualitäts sicherung kein reiner Job derTester ist, sondern alle Team mitgliederdurch spezifische Maßnahmen zur Stei -gerung der Qualität beitragen können.

Sollten Sie Fragen und Anregungen zumdargestellten Prozess und den Werkzeugenhaben, helfen wir Ihnen gerne weiter! ■

für einen Build-Test-Report zeigt Abbil -dung 11. Neben der reinen Gesund heits -prüfung ist dieser spezielle Build auch fürdie Erstellung der Testversion der Softwarezuständig. Aufgrund der vielfältigenVorprüfungen hat diese Version fast schoneinen „Release“-Charakter.

Eine TFS-Besonderheit bei den Builds bil-det der Gated Check-In Build. Hier wird imGegensatz zum CI-Build ein Build vor demjeweiligen Check-In-Vorgang erzwungen,und im Fehlerfall werden Änderungen derEntwickler vom Server abgelehnt. Ein CI-Build wird hingegen immer erst ausgelöst,wenn Änderungen in der Versionskontrollebereits eingecheckt sind. Dadurch, dassGated Check-In Builds nicht umgangenwerden können und Änderungen vor demCheck-In geprüft werden, können kritischeBereiche wie z. B. „release“-Zweige, aufdenen nur ab und an eine Fehlerbehebungerfolgt, besonders geschützt werden.

schnell identifiziert werden können. DerRolling Build als Besonderheit fasst imWesentlichen mehrere Eincheck-Vorgängein einem Build-Durchlauf zusammen,sodass sich Build-Zeiten verringern lassen.

Als nächster Schritt wird die Hauptlinie(„main“) mit einem täglich laufendenBuild-Prozess (Scheduled Build) weiterenautomatischen Prüfungen, wie statischenCode-Analysen (z. B. mit FxCop oderStyleCop), weiteren automatisierten Tests(z. B. Integrationstests), Sandcastle-Doku -mentationserstellung oder Setup-Erstel -lung, unterzogen. Der tägliche Build fun-giert damit für das Team als regelmäßigerumfassender „Gesundheitscheck“. Durchdie tägliche Ausführung eignen sich dieerfassten Kennzahlen (Code Coverage, sta-tische Code-Analyse, Anzahl geändertenCodes, etc.) auch gut, um über Reports denIst-Zustand sowie den Trend bzgl. derQualität beurteilen zu können. Ein Beispiel

advertorial

5 www.objektspektrum.de

Abb. 11: Build Sucess Over Time.

Referenzen

[Ait] AIT WordToTFS, siehe http://www.aitgmbh.de/downloads/kostenlose-tools/ait-wordtotfs-word2tfs.html.

[Cha-1] REDEFINING QUALITY ASSURANCE – AN ALM PERSPECTIVE, siehe

http://www.davidchappell.com/writing/white_papers/Redefining_QA--Chappell.pdf.

[Cha-2] WHAT IS APPLICATION LIFECYCLE MANAGEMENT?, siehe

http://www.davidchappell.com/writing/white_papers/What_is_ALM_v2.0--Chappell.pdf.

[Sig-1] Ausweg aus der Kommunikationskrise oder das Ende von „Bei mir funktioniert’s“?, siehe

http://www.sigs-datacom.de/fileadmin/user_upload/zeitschriften/os/2010/Testing/orschel_OS_TESTING_2010.pdf.

[Sig-2] OBJEKTspektrum Online-Themenspecials: Requirements Engineering, siehe

http://www.sigs-datacom.de/fachzeitschriften/objektspektrum/online-themenspecials/artikelansicht.html?show=2920.

[Vsa] Visual Studio Team Foundation Server Branching and Merging Guide, siehe http://vsarbranchingguide.codeplex.com/releases.