Kürzere Testvorbereitungsphasendurch integrierte TestlaboreDie aktuellen Release-Zyklen von Software-Projekten haben sich in den letzten Jahren eher verkürzt, u. a. weil agileVorgehens modelle sich in dieser Zeit rapide verbreitet haben und damit einhergehend Entwicklungs- und Testzyklen kürzerwurden. Dies stellt alle Projektbeteiligte vor neue Herausforderungen, wie z. B. viele Zwischen-Softwareversionen inTestumgebungen effizient bereitzustellen sowie die Sicherstellung der Lauffähigkeit von bereits implementiertenFunktionalitäten durch automatisierte Tests. Im Vorjahresartikel (siehe [1]) konnte bereits der Austausch von Informationenzwischen Tester und Entwickler durch den Einsatz vom Team Foundation Server (kurz TFS) und dem Microsoft Testmanager(kurz MTM) optimiert werden. Der Fokus lag hierbei primär darauf, die Bereiche Testmanagement und Bugtracking über diegemeinsame Entwicklungsplattform Team Foundation Server zu integrieren und Bug-Reports, mit automatisch im Hintergrunderfassten Diagnoseinformationen, für eine bessere Reproduzierbarkeit zu erstellen. Ein unscheinbarer Bereich mit massivemEinsparpotenzial ist nach unserer Erfahrung der Betrieb und das Management von Testumgebungen. In der Testvorbereitungs -phase schlummert zusätzlich noch eine Menge ungenutztes Potenzial bei der automatischen Bereitstellung der Testobjekte indie Testumgebungen. In diesem Artikel zeigen wir Ihnen Wege, wie Sie diese Herausforderungen effizient und effektiv mit demVisual Studio 2010 Lab Management meistern können.

Funktionalität kann die Testabteilung vir-tuelle und physische Testumgebungen ein-facher verwalten. Bei virtuellen Umgebu genbedeutet dies, dass man in Eigenregie ein-

schon zu spät ist. An diesem Punkt kanndas TFS 2010 Lab Management sowohlden Tester als auch den IT-Administratorentlasten. Mit der TFS-Lab-Management-

Einfache Bereitstellung von

Testumgebungen

Bei vielen unserer Kunden beginnen dieTestvorbereitungen mit der Bereitstellungvon Testumgebungen durch eine dedizierteinterne IT-Abteilung, die für die Bereit -stellung und den Betrieb zuständig ist. Einesolche „einfache“ Bereitstellung vonTestumgebungen kann aufgrund von eta-blierten IT-Betriebs- und Bereitstellungs -prozessen gerade bei mittleren bis großenUnternehmen mitunter mehrere Wochen inAnspruch nehmen. Die Bearbeitungsdauersteht damit in direktem Widerspruch zuden Testzyklen bei agilen Entwicklungs -prozessen. Für agile Teams ist eine poten-zielle Dauer von drei bis vier Sprintsschlichtweg untragbar. Unterstellt mandann noch die für einen agilen Prozess typi-schen sich verändernden Rahmenbedin gun -gen und Anforderungen, dann bekommtein Team die Testumgebung immer dannzur Verfügung gestellt, wenn es eigentlich

der au tor

Nico Orschel

(E-Mail: nico.orschel@aitgmbh.de)ISTQB zertifizierter Software-Tester und Berater des AIT TeamSystemProTeams. Hat sich u. a. anderem auf das automatische Testen mit dem VisualStudio Lab Management spezialisiert. Berät Unternehmen bei der Einführungund Anpassung des Visual Studio Team Foundation Server. Seine Erfahrungenvermittelt er zudem als Autor des TFS-Blogs, in Magazinen und in Vorträgen.

1 www.objektspektrum.de

advertorial

Abb. 1: TFS 2010 Lab Management Infrastruktur

fach und schnell virtuelle Maschinen erstel-len, ändern und löschen kann. ImFolgenden werden wir uns auf den Typ dervirtuellen Testumgebungen beschränken,weil nur diese den vollen Leistungsumfang

zur Verfügung stellen. Über Unterschiedezwischen beiden Testumgebungstypeninformiert das Whitepaper unter [2].

Die technische Basis für den Betrieb vonvirtuellen Umgebungen bilden Server mit der

Microsoft Virtualisierungslösung Hyper-V(siehe Hyper-V Host in Abbildung 1).

Ein oder mehrere dieser Server werdenüber die Managementlösung System CenterVirtual Machine Manager 2008 R2 (kurzSCVMM) an den TFS angebunden. AlleHyper-V-Hosts aus Abbildung 1 werdenzentral über SCVMM Library Shares mitSoftware und Vorlagen von virtuellenMaschinen und vorkonfigurierten Testum -ge bun gen versorgt. Der SCVMM ist bereitsohne zusätzliche Lizenzkosten Teil der Lab-Management-Lizenz (Lizenzierungsdetailssiehe [3]). Diese wiederum ist Teil derProgrammpakete Test Professional (Micro -soft Testmanager) und Visual Studio 2010Ultimate.

Als Tester sehen Sie von diesen techni-schen Details im Hintergrund nichts, dennSie verwalten diese Testumgebungen nurüber ihren MTM in der Lab-Center-Perspektive (siehe Abbildung 2). Die zwei-

2Online-Themenspecial Testing 2011

Online-Themenspecial Testing 2011 advertorial

Abb. 2: Microsoft Testmanager 2010 Lab Center

Abb. 3: Anlegen einer Testumgebung im MTM

einem IT-Administrator diese Frage stellt,dann wird man sicherlich die Antworterhalten, dass dies technisch nicht möglichist. Man hört in dieser Situation techni-schen Ausführungen wie u. a., dass Rech -nername und IP Adresse im Netzwerk stetseindeutig sein müssen (siehe Abbildung 4).

Genau für diesen Anwendungsfall wurdebeim TFS 2010 Lab Management dieFunktion „Network Isolation“ eingeführt.Mit Hilfe eines Dienstes – dem sogenann-ten Lab Agent – in den virtuellenMaschinen (siehe Abbildung 1 undAbbildung 5) können diese voneinanderisoliert betrieben werden, obwohl es sichum Klone handelt. Das Duplizieren istdank dieser Funktion so einfach wie dasKopieren einer CD.

Ein weiterer positiver Nebeneffekt dieserFunktion besteht darin, dass Sie somit derEntwicklungsabteilung Duplikate ihrerUmgebungen zur Verfügung stellen kön-nen. Im vorherigen Artikel wurde bereitsdas Konzept der Rich-Bugs, d. h. Bugs mitzusätzlichen Diagnoseinformationen vorge-stellt. Trotz dieser vielen Informationen las-sen sich Fehler in Entwicklungsumge -bungen nicht immer nachvollziehen undman benötigt als Entwickler besser dieursprüngliche Testumgebung des Testers.Mit der Duplizierungsfunktion kann manals Tester einfach die Umgebung duplizie-ren und dem Entwickler zur Verfügung stel-len. Ein Beispiel für dieses Szenario im Falleeines Fehlers zeigt Abbildung 6. Mehrnoch, es lässt sich ein Link auf denSnapshot der virtuellen Maschine zumZeitpunkt des Fehlereintritts anhängen unddem Entwickler somit die gesamte „einge-frorene“ Testumgebung übermitteln.

Kompilieren, Ausliefern und

Testen

Nachdem die Testumgebungen durch denMTM und Lab Management bereitgestelltwurden, bleibt noch der Punkt derBereitstellung von Testobjekten durch dieEntwicklung offen. Bei der Bereitstellungvon Testobjekten folgt das aktuelle Kapitelder Methodik „Continous Delivery“.

Continous-Delivery-Prozesse (im Folgen -den kurz CD genannt) bestehen aus dreiPhasen: Übersetzen der Lösung, Ausliefernoder Installieren der Lösung in einerZielumgebung und abschließend dieAusführung von automatisierten Tests. Andieser Stelle fällt sofort die Ähnlichkeit zudem weitverbreiteten Begriff ContinousIntegration (im Folgenden kurz CI) auf. CI

stellen, so als würden sie mit Legosteinenbauen. Abbildung 3 zeigt diesen sehr einfa-chen Prozess, wie die Tester mit nur vierSchritten Testumgebungen bereitstellenkönnen. In der Abbildung wird in Schritt1. zunächst der Umgebungstyp „VirtualEnvironment“ ausgewählt, um die zuvorbeschriebenen Vorlagen als Basis für eineneue Testumgebung auszuwählen. InSchritt 2 hat die Auswahl der Vorlagendann stattgefunden. Danach müssen im 3.Schritt noch die notwendigen Eigenschaf -ten der Testumgebung, wie Workflow-,Testing- und Network-Isolation-Unterstüt -zung aktiviert werden. Die Eigenschaftensind notwendig, um Deployment-Skripteauszuführen, sowie für automatische Testsund das Sammeln von Diagnosedaten. InSchritt 4 können Sie die Erstellung mitFinish starten.

Wichtig bei der Testausführung ist dieIsolation unterschiedlicher Tester, umgegenseitige Auswirkungen von Tests zuminimieren. Diese Anforderung macht esnotwendig, Testumgebungen für jedenbeteiligten Tester zur Verfügung zu stellen.Unter normalen Umständen bedeutet dies,dass Sie den Prozess aus Abbildung 3 fürjeden Tester x-mal wiederholen. DerNachteil dieser Vorgehensweise ist geradebei komplexen Testumgebungen der hoheZeitaufwand und die Fehleranfälligkeit beider Konfiguration und zusätzlichen Instal -lationen. Wäre es nicht schön, wenn Sieden Aufwand der Testumgebungsvor -bereitung nur einmal tätigen müssten undanschließend einfach für jeden Tester einexaktes Duplikat anzufertigen? Wenn man

te Perspektive des MTM ist das bekannteTest-Center für das Testmanagement unddie Testausführung (siehe [1]).

Jetzt stellt sich hier natürlich die Frage:Welche Schritte sind für die Bereitstellungeiner virtuellen Testumgebung mit demMTM notwendig? Der Bereitstellungs -prozess beginnt damit, dass die interne IT-Abteilung Vorlagen von virtuellen Ma -schinen nur einmalig erstellt (siehe LibraryShare in Abbildung 1). In diesen Vorlagenwerden dabei Software-Agenten der TFSPlattform (Build Agent, Test Agent und LabAgent) zur Fernsteuerung und weitereSoftware (in Abhängigkeit vom Testszena -rio) vorinstalliert. Anschließend werdendiese generalisiert (Fachwort: syspreping)und dann über den SCVMM Library Shareden MTM-Clients zur Verfügung gestellt,so dass später auf ihrer Basis nach Bedarfneue Maschinen erzeugt werden können.Nachdem man eine Vorlage in die LibaryShare kopiert hat, müssen diese einmaligim Lab Center registriert werden. Bei die-sem Registrierungsprozess werdenStandardwerte für Computereinstellungen,wie z. B. Rechnername, Speicher, Admi -nistrator-Konto, Administrator-Passwortund Lizenzschlüssel hinterlegt, damitAnwender diese Daten nicht bei jedemAnlegen von Testumgebungen bei der IT-Abteilung erfragen bzw. doppelt und drei-fach eintragen müssen. Ist die Vorlageerfolgreich im Lab-Center registriert, dannkönnen Tester Testumgebungen, bestehendaus einem oder mehreren Rechnern, aufBasis dieser Vorlagen einfach zusammen-

advertorial

3 www.objektspektrum.de

Abb. 4: Duplizieren einer Testumgebungohne Network Isolation

Abb. 5: Duplizieren einer Testumgebungmit Network Isolation

besteht aus der Prozesssicht aus zweiHauptphasen: Übersetzen der Lösung undanschließendes Ausführen von Unit Tests.Die Unterschiede liegen dabei zum einendarin, dass CI-Build-Prozesse keine Soft -ware in Zielumgebungen ausliefern undzum anderen, dass nur Modul- bzw.Kompo nententests (Unit Tests) in Isolationausgeführt werden. CI verfolgt im Gegen -satz zum CD das Ziel, schnell Feedbackan die Entwickler zu liefern. CD hin-gegen führt die Tests anTestobjekten in den jeweiligenZielumgebungen aus. Die Ziel -umgebungen sind dabei anden Produktiv umgebungenangelehnt. Desweiteren set-zen die Tests eine lauffähigeSoftware für die Ausfüh -rung voraus. Die auszufüh-renden Tests haben alsFokus die TestphasenSystem test oder Akzeptanz -test und sind dadurch szena-rio-orientiert – prüfen alsopotentiell das Software-Produktals Gan zes. Zusammengefasst stelltCD erstmals die Verbindung zwischenTestumgebung und Release-Prozess her.Es ist damit ein „CI plus“.

Der zuvor beschriebene CD-Prozess istbeim TFS 2010 über eine spezielle Build-Workflow-Vorlage mit dem Namen

LabDefaultTemplate.xaml realisiert, wel-che bereits alle notwendigen Basisschrittezur Verfügung stellt. Microsoft hat mit demWorkflow einen Release-Prozess entspre-chend der Darstellung in Abbildung 7 rea-lisiert, welcher neben der Infrastruktur -

thematik aus dem vorherigen Abschnittzum Begriff Lab Management zusammen-gefasst wird.

Ein Lab Management Workflow sorgt zuBeginn für die Übersetzung des jeweiligenCodes. Technisch gesehen führt der LabManagement Workflow einfach einenbereits existierenden Release-Build-Prozessder Entwicklung aus, so dass man fürTestumgebungen und spätere Releases nureinen Build-Prozess pflegen muss. Nach derKompilierungsphase stellt der Workfloweine Verbindung zu den Testumgebungenher und setzt diese im Fall von virtuellenTestumgebungen auf einen definiertenStand (Fachwort: Abbild oder Snapshot)zurück. Nachdem die Verbindung herge-stellt wurde, wird die Anwendung überSkripte oder Installationsprogramme in dieTestumgebung ausgerollt. Die Art undWeise des Rollout-Verfahrens ist abhängigvom jeweiligen Artefakttyp (Programm,Website, Datenbankskript, Testdaten).Nach dem Rollout wird im Fall von vir-tuellen Testumgebungen ein weiteresAbbild der Testumgebung erzeugt. Diesesspezielle Abbild hat den Vorteil, dass Testerund Entwickler ihre Umgebungen zu jedemZeitpunkt in einen nicht durch Tests beein-flussten Zustand zurücksetzen können.Werden Testobjekte in der Testumgebungbereitgestellt, starten anschließend dieautomatischen Tests in der Testumgebung.Die hier ausgeführten Tests sind nicht mehrwie bei CI auf die Modul- oder Komponen -

tenebene begrenzt, sondern die Anwen -dungen können auch direkt ausge-

führt werden. Zum Testen vonOberflächen (wie z. B.

WinForms, WPF, Silverlight,Weban wendungen im IE undFirefox) kann man hier dasneue CodedUI Frameworkeinsetzen. Die auszuführen-den Tests werden überTestfälle, welche überTestpläne und Testsuiten imTFS 2010 strukturiert sind,

ausgewählt (Testfall manage -ment mit MTM siehe [1]).

Wenn ein Fehler auftritt bzw.ein Testfall nicht erfolgreich war,

dann kann der Tester die Test -umgebung im Fehlerzustand „einfrie-

ren“, so dass der Entwickler neben denTestprotokollen auch eine Testumgebungzur Fehlerdiagnose zur Verfügung hat.

Auf den ersten Blick scheint der beschrie-bene Workflow recht kompliziert zu konfi-

4Online-Themenspecial Testing 2011

Online-Themenspecial Testing 2011 advertorial

Abb. 6: Wiederherstellung einer Testumgebung im Fehlerfall

Abb. 7: Lab Management Workflow

zur Verfügung stehen, so dass manuellerAufwand sowohl auf Seiten derQualitätssicherung- und Entwicklungs -abteilung eingespart werden kann. Das TFSLab Management umfasst bereits einenStandard-Workflow, welcher der Methodik„Continuous Delivery“ folgt. Konkretbedeutet dies, dass er bereits die„Continuous Delivery“ – Phasen Kompi -lieren, Ausliefern und Testen unterstützt.Im Rahmen des Schrittes Testen wirdbereits eine erste Eingangsprüfung überautomatisierte Tests durchgeführt, so dassnur Programme mit bestimmten Quali täts -standards ihren Weg in die manuellenTestphasen finden.

Zeit zu kopieren. Umfangreiche Konfigu -rations- und Installationsarbeiten könnenso eingespart werden und Tester könnensich auf die Testspezifikation und -ausfüh-rung konzentrieren. Die Lab-Management-Infrastruktur hat zusätzlich noch den posi-tiven Nebeneffekt, dass Tester ihreTestumgebungen mit den Entwicklern „tei-len“ können. Die Entwickler könnendadurch beim Testen und beimNachvollziehen von Fehlern auf die glei-chen Testumgebungen zugreifen. Durch dieenge Verzahnung von Build-Prozessen derEntwicklung mit den Testumgebungenkönnen neue Releases schnell, regelmäßigund automatisiert in den Testumgebungen

gurieren, er lässt sich aber dank derAssistenten im Visual Studio 2010 schritt-weise einrichten (technische Details siehe[2]).

Fazit

Der Artikel zeigt Ihnen Wege, wie Sie mit-hilfe des TFS 2010 Lab Management dieTestvorbereitungsphase optimieren kön-nen. Die Bereitstellung von Testumge -bungen im Baukastenprinzip kann mithilfedes MTM durch Tester stark vereinfachtwerden. Für die Tester wird dabei kein neu-es Werkzeug benötigt, sondern es wird nureine andere Perspektive des MTM (LabCenter) genutzt. Die interne IT-Abteilungkann durch diese neue Arbeitsweise starkentlastet werden, weil sie nicht mehr jedeUmgebung individuell aufsetzen, sondernjetzt nur noch Vorlagen für virtuelleMaschinen sowie die entsprechenden Host-Systeme zur Verfügung stellen müssen.Gerade bei agilen Projekten gehörenWartezeiten von mehreren Sprints dankdieser neuen Möglichkeiten der Vergan -genheit an. Zusätzlich haben Tester nun dieMöglichkeit, wenn einmal eine komplexeUmgebung aufgesetzt ist, diese einfachdurch die Duplizierungsfunktion (NetworkIsolation) ähnlich wie eine CD in kürzester

advertorial

5 www.objektspektrum.de

Referenzen

[1]: Ausweg aus der Kommunikationskrise oder das Ende von „Bei mir funktioniert’s“?:

http://www.sigs.de/publications/os/2010/Testing/orschel_OS_TESTING_2010.pdf

[2]: Whitepaper Lab Management: http://www.aitgmbh.de/labmngwhitepaper

[3]: Visual Studio 2010 and MSDN Licensing White Paper:

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=13350

[4]: Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment

Automation, Addison-Wesley Longman, ISBN: 0321601912