Ausweg aus der Kommunikationskrise oderdas Ende von „Bei mir funktioniert’s“?Die Auslieferung von hoch qualitativen Anwendungen ist das Ziel von allen Softwareentwicklungshäusern. Über die Zeit habensich zwei Gruppen (Entwicklung und Qualitätssicherung) herausgebildet, welche für ihre Arbeit wiederum eigene Tools eingesetzthaben. Die eingeführten Werkzeuge bildeten Informationsinseln mit vielen Medienbrüchen und ohne große Möglichkeiten desAustauschs. Was folgt sind erhöhte Kommunikationsbarrieren zwischen Entwicklung und Test, die die Arbeit ineffektiv machen.Die Probleme spitzen sich im sogenannten „Bug Pingpong“ zu, indem sich Qualitätssicherung und Entwicklung gegenseitig denSchwarzen Peter für fehlerhafte Software zuspielen. Im Artikel wird eine durchgängige Informations- und Kollaborationskette(vgl. (1)) unter Verwendung der Visual Studio 2010 Plattform (vgl. (2)) aufgezeigt. Es werden dabei zusätzlich Best Practices zumTestmanagement, manuellen und automatischen Testen mit der ALM-Plattform (Application Lifecycle Management) aus demHause Microsoft vorgestellt. Das Ziel des Artikels ist es, einen Weg aufzuzeigen, um die Kommunikationsbarrieren zwischenEntwicklung und Qualitätssicherung abzubauen.

Management“ (vgl. (4)) von meinemKollegen Herrn Hubert verweisen.

dem TFS möchte ich Sie gerne auf denArtikel „Durchgängiges Requirements

Der Anfang ... Definition und

Planung von Anforderungen

Zu Beginn jeder Softwareentwicklung wer-den in allen Softwarehäusern zunächstAnforderungen an die Software definiert.Art, Umfang und Begrifflichkeiten derAnforderungen können dabei zwischen denverschiedenen Vorgehensmodellen variie-ren. Im Kontext der Entwicklung mit demTeam Foundation Server (kurz: TFS) wer-den die Anforderungen mit bekanntenTools wie Visual Studio 2010, Excel oderWord erfasst. Für das zuletzt genannte Toolhat die AIT AG das Addon „WordToTFS“(vgl. (3)) zur Synchronisation von Anfor -derungen zwischen Word Dokument undTeam Foundation Server erstellt (sieheAbbildung 1 – WordToTFS).

Die Definition und Erfassung führendabei das Produktmanagement sowie dieProjektmanager von Entwicklung undQualitätssicherung gemeinsam durch. Alleim TFS gespeicherten Requirements wer-den dabei als sogenannte Work Itemsgespeichert. Für einen tieferen Einblick indas Thema Requirements Management mit

der au tor

Nico Orschel

(E-Mail: nico.orschel@aitag.com)ist Microsoft Certified Trainer und Berater des AIT TeamSystemPro Teams. Erhat sich unter anderem auf das automatische Testen mit dem Visual StudioLab Management spezialisiert. Er berät Unternehmen bei der Einführung undAnpassung des Visual Studio Team Foundation Server. Seine Erfahrungen ver-mittelt er zudem als Autor des TFS-Blogs (tfsblog.de)

1 www.objektspektrum.de

advertorial

Abbildung 1 - WordToTFS

Definition und Planung

von Testfällen

Nachdem die Anforderungen im TeamFoundation Server erfasst sind, beginnt dieArbeit der Qualitätssicherungsabteilung(kurz: QS) auf Seiten des Softwarehauses,aber auch je nach Projektsituation unterEinbeziehung des Kunden. Mit der Veröf -fentlichung der Visual Studio 2010 Pro -duktfamilie bekommt unsere QS ein eige-nes Werkzeug für das Testmanagement,dem Microsoft Test Manager 2010 (kurz:MTM). Der MTM besteht aus zweiBereichen, Testing Center und Lab Center.Zunächst bewegen wir uns nur im TestingCenter, denn dieser ist für das Managementvon Tests und das manuelle Testen verant-wortlich. Das Lab Center hingegen ist fürdie Verwaltung von Testumgebungen fürQS und Entwicklung zuständig.

Im MTM arbeitet die QS in sogenanntenTestplänen. Der Testplan definiert denRahmen für das Testen wie Team Projekt,Start- und Enddatum einer Testphase,Testplanverantwortlicher, Testkonfigura -tionen sowie die bei der Testausführung zuerfassenden Diagnosedaten.

Die Testeinstellungen definieren, welcheInformationen bei der Ausführung vonTests automatisch im Hintergrund aufge-zeichnet und im Fehlerfall reportet werdensollen. Es ist dabei möglich, z. B. alleAktionen des Benutzers auf der Oberflächeaufzuzeichnen (ActionLog), ein Video desTestdurchlaufs zu erstellen, Daten aus demEventLog einzusammeln, den aufgerufenen

Code aufzuzeichnen (IntelliTrace) oder dieBandbreite der Netzwerkverbindung einzu-schränken (siehe Abbildung 2).

Die aufgeführten Adapter sind dabei nochflexibel um eigene Adapter erweiterbar. EineBeispielerweiterung ist der IP AddressCollector vom Autor aus Abbil dung 2. Jenach Produkt-, Test- und Projektstrukturdefiniert die QS ein oder mehre Testpläne proTeam Projekt. Ein Team Projekt definiert ver-einfacht gesprochen einen Rahmen in Formvon Work Item Typen, Reports, SourceControl, Build-Prozessen, Testumgebungensowie Testplänen für das gesamte Produkt -team. In unserer Arbeit hat sich die Struk -turierung und Benennung von Testplänennach Produktversion und Testart etabliert.

Nachdem Testpläne erstellt wurden, gehtes darum, die vielen Testfälle pro Testplanbesser zu strukturieren. Pro Version unsererSoftware und Testart können schließlichmehre hunderte Testfälle existieren. DieStrukturierung innerhalb von Testplänengeschieht mit sogenannten Testsuiten. DerTFS kennt dabei drei Arten von Testsuiten:Testsuites, Query-based Testsuites undRequirements. Testsuites verhalten sich wieOrdner in Windows, d. h. sie ordnenTestfälle manuell zu bzw. entfernen siemanuell. In Query-based Testsuites werdenTestfälle auf Basis von Abfragen (TFS:Work Item Queries) angezeigt. Erfüllt einTestfall Work Item eine bestimmteBedingung nicht mehr, so wird es nichtmehr in der Testsuite angezeigt. EineQuery-based Testsuite fungiert hier nur alseine dynamische Sichtweise auf eine großeAnzahl an Testfällen. Eine Anwendung fürdie Query-based Testsuite wäre die Anzeigealler Testfälle mit hoher Priorität. Der drit-te Testsuite-Typ ist ein Spezialfall. DieAnforderungen, welche wir bereits amAnfang unseres Entwicklungsprozesses imTFS erfasst haben, werden dabei alsOrdner im Testplan abgebildet (sieheAbbildung 3).

Wenn jetzt die QS einen Testfall in diesespezielle Testsuite einordnet, so wird imHintergrund automatisch eine Verknüp -fung zwischen Anforderung und Testfallerstellt. Diese Verknüpfung steht in allenTools, wie z. B. Visual Studio, Eclipse,Excel werkzeugunabhängig zur Verfügung.Durch die Verknüpfungen und Abfragenlassen sich jetzt auch Informationen gewin-nen, wie „Welche Anforderungen habenTestfälle?“ oder noch interessanter „Fürwelche Anforderungen fehlen noch

2Online-Themenspecial Testing 2010

Online-Themenspecial Testing 2010 advertorial

Abbildung 2 - MTM - Daten und Diagnose

Abbildung 3 - Testpläne im MTM

Testfälle?“. Die Navigation zwischenAnfor derungen und Testfällen ermöglichtallen Beteiligten, den Kontext sowohl ausder Entwicklungs- und Testperspektive bes-ser zu verstehen und so schlussendlich bes-sere Software durch bessere Kommunika -tion zu erstellen.

Die zuvor angesprochenen Testfälle sindim TFS auch nur Work Items. Ein Beispiel fürein Testcase Work Item zeigt Abbildung 4.

Ein Work Item setzt sich im TFS aus allge-meinen und spezifischen Informationenzusammen. Beispiele für allgemeine Infor -mationen sind Bearbeiter, Titel und Zustand.In der Standarddefinition eines Testfalles sinddie Zustände „Design“, „Ready“ und„Closed“ hinterlegt. Die wichtigsten spezifi-schen Informationen im Testfall Work Itemsind Teststeps und Testautomation.

In den Teststeps werden Schritte be -schrieben, welche ein Fachtester bei derTestdurchführung ausführen soll. Nebenden Schritten kann dabei auch das erwarte-te Ergebnis angegeben werden. Wird einsolches Ergebnis für einen speziellenTestschritt angegeben, so wird von einemValidationstep gesprochen. Die eingegebe-nen Testschritte lassen sich noch weiteroptimieren. Weil bei vielen Testfällen oftbestimmte Teilschritte immer identischsind, lassen sich diese Schritte in einen spe-ziellen Testfall Work Item Type mit demNamen „Shared Step“ auslagern. Ein

„Shared Step“ lässt sich in ein oder mehre-re Testfälle einbinden. Ein typisches An -wendungsbeispiel ist der Login- Dialog beieiner Anwendung.

Der zweite Optimierungspunkt wäre dieParametrisierung unseres Testfalles. Durchdas Anfügen eines @ - Zeichens könnenParameter sowohl für den Testschritt alsauch für das erwartete Ergebnis erzeugt

werden. Durch Verwendung von Parame -tern muss nicht für jedes Testwertpaar einneuer Testfall erzeugt werden (sieheAbbildung 4).

Der zweite wichtige Teil eines TestfallWork Items ist das Tab „Associated Auto -mation“. Über dieses Tab Testautomationkann eine Beziehung zwischen einem auto-matisierten Test und einem Testfall im TFShergestellt. Durch die Verknüpfung kannder automatisierte Testfall wie ein manuel-ler Testfall verwaltet, ausgeführt und aus-gewertet werden. Der Fachtester hat zudemden Vorteil, dass er bei Problemen mit demautomatisierten Test sofort auf das VisualStudio Projekt rückschließen kann, wasgerade bei der Abstimmung mit dem ver-antwortlichen Entwickler eine Menge Zeitsparen kann.

Eine weitere Möglichkeit Ressourcen zuschonen, ist die Möglichkeit der Ermittlungvon empfohlenen Tests auf Basis von geän-derten Codezeilen (MTM: RecommendedTests). Ausführung von Tests

Nachdem die Testfälle spezifiziert sind undsich im Zustand „Ready“ befinden, wechselnwir im MTM auf das Tab „Test“. Im Tab„Test“ finden wir erneut unsere Testsuitenaus der Planungsphase. In der aktuellenAnsicht haben Sie die Mög lichkeit auf denTesternamen, sowie die zu testendeTestkonfiguration zu filtern. Beispiele fürTestkonfigurationen sind Betriebssystemoder Sprache. Ein Testfall kann einer oder

advertorial

3 www.objektspektrum.de

Abbildung 4 - Test Case Work Item

Abbildung 5 - Testrunner

mehreren Konfigurationen zugeordnet sein.Nachdem Tester und Konfiguration ausge-wählt sind, können wir einen Testlauf (TFS:Testrun) starten. Im Rahmen eines Testrunskann ein spezieller Testfall oder alle Testfälleeiner kompletten Testsuite ausgeführt wer-den. Bei der Ausführung einer Testsuiteschaltet der MTM in den „Testrunner“Modus, dabei schaltet er erneut in eine opti-mierte Ansicht und verkleinert zusätzlich denDesktop des Testers um Übersicht zu bewah-ren (siehe Abbildung 5).

In diesem Modus führt der Tester alleTestschritte aus und meldet Erfolg oderMisserfolg mit Pass oder Fail. Aus demTestrunner heraus kann der Tester imFehlerfall direkt bei der Testausführungeinen Bug erstellen. Wird ein Bug erzeugt, sobeginnt der MTM sofort mit demEinsammeln von Diagnosedaten. Ein Beispielfür einen solchen Richbug zeigt Abbildung 6.

Der mit umfangreichen Diagnosedaten,wie z. B. Video, EventLog, ActionLog undTestschritte mit Videozeitmarken undaktueller Testparameter angereicherte Bugwird als „Richbug“ bezeichnet. In Kombi -nation mit dem Lab Management geht derProzess sogar soweit, dass an den Bug aucheine Verknüpfung zur passenden Testum -gebung angefügt wird. Auf diese Weiseerzeugte Bugs haben drastische Vorteilegegenüber Bugs aus klassischen BugTracking Systemen: Sie entlasten denTester, indem der MTM das Einsammelnder technischen Diagnosedaten für dieTestschritte automatisiert und so schlus-sendlich eine neue Art der Kommunikationzwischen Tester und Entwickler über Bugsermöglicht. Der große Vorteil für denEntwickler wiederum besteht darin, dass erjetzt viele Informationen bekommt, umFehler besser nachstellen zu können. DieInformationen außerhalb der rein textuel-len Beschreibung wie Video, IntelliTraceDatei (vgl. (5)) und der mögliche Link aufverwendete Testumgebungen ermöglichtdem Entwickler, schneller Fehler zu finden.IntelliTrace Dateien stellen dabei eine ArtFlugschreiber der Testausführung dar, d.h.der MTM oder Test Agent sammeltInformationen über den aufgerufenen Codewährend der Testausführung. UnterVerwendung des Visual Studio 2010Ultimate kann der Entwickler die histori-sche Aufzeichnung quasi schrittweise nach-spielen und nachvollziehen, wie dieFehlersituation auf einem fremden Rechnerentstanden ist, ohne das er am Testsystemangemeldet ist.

Neben der Erstellung von Bugs kann derTestrunner auch alle Aktionen auf derOberfläche verfolgen und bei einem späte-ren Regressionstest erneut abspielen. Daserneute Nachspielen von Aktionen bis zu

interessanten Testschritten wird als „FastForward Testing“ (vgl. (6)) bezeichnet. Dieso erzeugten Aufnahmen heißen im MTMActionLogs und werden ebenfalls proTestfall Work Item im TFS zentral gespei-

4Online-Themenspecial Testing 2010

Online-Themenspecial Testing 2010 advertorial

Abbildung 6 - Richbug

Abbildung 7 - Test Results

zeigt Abbildung 8. Sie haben über dasReporting aber auch die Mög lichkeit, einfa-chere Auswertungen mit reinem Testfokuswie z. B. Testfort schritts analysen zu erstellen.

Fazit

Mit der neuen Visual Studio 2010 Familiehat es Microsoft geschafft, auch den AspektTestprozesse in die durchgängigeInformationskette im Team FoundationServer zu integrieren. Testartefakte sind jetztnicht mehr separat in eigenen Werkzeugenabgelegt, sondern stehen direkt in einerBeziehung zu Anfor derungen, Bugs,Quellcode und Build-Prozessen. Diese tiefeIntegration ermöglicht eine nie da gewesenedirekte Zu sammenarbeit und Kommunika -tion zwischen Entwicklung und QS.

Des Weiteren entlasten die neuen Test -werkzeuge den Tester durch einen hohenAutomatisierungsgrad bei der Kom mu ni -kation mit dem Entwickler, indem die rele-vanten technischen Daten für denEntwickler im Hintergrund an denEntwickler extrahierbar sind. Diese sindauch für einen Fachanwender relativ einfachnachvollziehbar. Eine weitere Entlastung füralle Beteiligten lässt sich durch dieEinführung von automatisierten Ober -flächentests (TFS: CodedUI Tests) (vgl. (10))um das Testen in virtuellen Testumgebungen(TFS: Lab Management) (vgl. (11) ) erzielen.Der Einsatz vom Lab Management undCoded UI Tests ist nicht inhaltlicher Fokusdieses Artikels.

Zudem ist hervorzuheben, dass trotz derIntegration jeder Anwender seine gewohn-ten bzw. speziellen Werkzeuge nutzen kannund alle dennoch über den zentralen TFSzusammenarbeiten können. ■

Auswertung von

Testergebnissen

Alle Daten, welche sowohl bei der Planungund Ausführung von Tests entstanden sind,werden stets im TFS zentral abgelegt. Durchdie zentrale Speicherung können alle Betei -ligte die Ergebnisse von einzelnen Testläufenüber den MTM einsehen (siehe Abbildung 7).

Aufgrund der Verknüpfung von Anfor -derungen und Testfällen ist des Weiteren dieAuswertung von Testergebnissen im Kontextvon Anforderungen möglich, wodurch sichAussagen bzgl. der Qualität von einzelnenAnforderungen treffen lassen. Ein Beispiel füreine solche anforderungsbasierte Auswertung

chert. Damit der MTM Aktionen auf denOberflächen verfolgen kann, müssen dieControls von Programmen entweder denStandard Microsoft Active Accessibility(kurz:MSAA) (vgl. (7))) oder Microsoft UIAutomation (kurz: UIA (vgl. (8))) genügen.Aktuelle Microsoft .NET FrameworksTechnologien wie z. B. WinForms 2.0 undneuer, WPF 3.0 und neuer und Webseiten(HTML/AJAX) im IE 8 werden bereitsvollständig unterstützt (vgl. (9)). WeitereProgramme und Technologien, wieSilverlight oder Webanwendungen imFirefox testen, werden in nächster Zeitebenfalls möglich sein.

advertorial

5 www.objektspektrum.de

Abbildung 8 - Requirements Overview Report

Referenzen

[1] Visual Studio 2010 Editions [Online] http://www.microsoft.com/visualstudio/en-us/products/2010-editions

[2] MSDN Webcast: Traceability mit Team Foundation Server 2010 - Die Möglichkeiten im Überblick [Online]http://www.microsoft.com/germany/events/eventdetail.aspx?EventID=1032456802

[3] AIT WordToTFS 2010 [Online] http://www.aitgmbh.de/word_to_tfs0.0.html?&no_cache=1

[4] Durchgängiges Requirements Management – Eine integrierte ALM-Werkzeugkette für das Requirements Management auf Basis des TFS 2010[Online] http://www.sigs.de/publications/os/2010/RE/hubert_OS_RE_2010.pdf

[5] Debugging with IntelliTrace [Online] http://msdn.microsoft.com/en-us/library/dd264915.aspx

[6] Fast Forward Testing – Part 1 – The magic w(b)and. [Online]http://blogs.msdn.com/b/vstsqualitytools/archive/2010/01/07/fast-forward-testing-part-1-the-magic-w-b-and.aspx

[7] Microsoft Active Accessibility [Online] http://msdn.microsoft.com/en-us/library/ms971310.aspx

[8] Microsoft UI Automation [Online] http://msdn.microsoft.com/en-us/library/ms728097%28VS.85%29.aspx

[9] Platform Support for Coded UI Test (and Fast Forward feature of Test Runner) [Online],http://blogs.msdn.com/b/gautamg/archive/2010/01/07/platform-support-for-coded-ui-test-and-fast-forward-feature-of-test-runner.aspx

[10] Testing the User Interface with Automated UI Tests [Online] http://msdn.microsoft.com/en-us/library/dd286726.aspx

[11] Whitepaper: Lab Mangement [Online] http://www.aitgmbh.de/labmngwhitepaper (Veröffentlichungsdatum: 1.11.2010)