Ausweg aus der Kommunikationskrise oder das Ende von „Bei mir funktioniert’s“?
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

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

on

  • 582 views

 

Statistics

Views

Total Views
582
Views on SlideShare
582
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Ausweg aus der Kommunikationskrise oder das Ende von „Bei mir funktioniert’s“? Document Transcript

  • 1. advertorial der autor 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)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.Der Anfang ... Definition undPlanung von AnforderungenZu 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- Abbildung 1 - WordToTFSden dabei als sogenannte Work Itemsgespeichert. Für einen tieferen Einblick in dem TFS möchte ich Sie gerne auf den Management“ (vgl. (4)) von meinemdas Thema Requirements Management mit Artikel „Durchgängiges Requirements Kollegen Herrn Hubert verweisen. 1 www.objektspektrum.de
  • 2. Online-Themenspecial Testing 2010 advertorial Nachdem Testpläne erstellt wurden, geht es darum, die vielen Testfälle pro Testplan besser zu strukturieren. Pro Version unserer Software und Testart können schließlich mehre hunderte Testfälle existieren. Die Strukturierung innerhalb von Testplänen geschieht mit sogenannten Testsuiten. Der TFS kennt dabei drei Arten von Testsuiten: Testsuites, Query-based Testsuites und Requirements. Testsuites verhalten sich wie Ordner in Windows, d. h. sie ordnen Testfälle manuell zu bzw. entfernen sie manuell. In Query-based Testsuites werden Testfälle auf Basis von Abfragen (TFS: Work Item Queries) angezeigt. Erfüllt ein Testfall Work Item eine bestimmte Bedingung nicht mehr, so wird es nicht mehr in der Testsuite angezeigt. Eine Query-based Testsuite fungiert hier nur als eine dynamische Sichtweise auf eine große Anzahl an Testfällen. Eine Anwendung für die Query-based Testsuite wäre die AnzeigeAbbildung 2 - MTM - Daten und Diagnose aller Testfälle mit hoher Priorität. Der drit- te Testsuite-Typ ist ein Spezialfall. DieDefinition und Planung Code aufzuzeichnen (IntelliTrace) oder die Anforderungen, welche wir bereits amvon Testfällen Bandbreite der Netzwerkverbindung einzu- Anfang unseres Entwicklungsprozesses imNachdem die Anforderungen im Team schränken (siehe Abbildung 2). TFS erfasst haben, werden dabei alsFoundation Server erfasst sind, beginnt die Die aufgeführten Adapter sind dabei noch Ordner im Testplan abgebildet (sieheArbeit der Qualitätssicherungsabteilung flexibel um eigene Adapter erweiterbar. Eine Abbildung 3).(kurz: QS) auf Seiten des Softwarehauses, Beispielerweiterung ist der IP Address Wenn jetzt die QS einen Testfall in dieseaber auch je nach Projektsituation unter Collector vom Autor aus Abbildung 2. Je spezielle Testsuite einordnet, so wird imEinbeziehung des Kunden. Mit der Veröf- nach Produkt-, Test- und Projektstruktur Hintergrund automatisch eine Verknüp -fentlichung der Visual Studio 2010 Pro- definiert die QS ein oder mehre Testpläne pro fung zwischen Anforderung und Testfallduktfamilie bekommt unsere QS ein eige- Team Projekt. Ein Team Projekt definiert ver- erstellt. Diese Verknüpfung steht in allennes Werkzeug für das Testmanagement, einfacht gesprochen einen Rahmen in Form Tools, wie z. B. Visual Studio, Eclipse,dem Microsoft Test Manager 2010 (kurz: von Work Item Typen, Reports, Source Excel werkzeugunabhängig zur Verfügung.MTM). Der MTM besteht aus zwei Control, Build-Prozessen, Testumgebungen Durch die Verknüpfungen und AbfragenBereichen, Testing Center und Lab Center. sowie Testplänen für das gesamte Produkt- lassen sich jetzt auch Informationen gewin-Zunächst bewegen wir uns nur im Testing team. In unserer Arbeit hat sich die Struk- nen, wie „Welche Anforderungen habenCenter, denn dieser ist für das Management turierung und Benennung von Testplänen Testfälle?“ oder noch interessanter „Fürvon Tests und das manuelle Testen verant- nach Produktversion und Testart etabliert. welche Anforderungen fehlen nochwortlich. 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 Abbildung 3 - Testpläne im MTMOnline-Themenspecial Testing 2010 2
  • 3. advertorial werden. Durch Verwendung von Parame- tern muss nicht für jedes Testwertpaar ein neuer Testfall erzeugt werden (siehe Abbildung 4). Der zweite wichtige Teil eines Testfall Work Items ist das Tab „Associated Auto- mation“. Über dieses Tab Testautomation kann eine Beziehung zwischen einem auto- matisierten Test und einem Testfall im TFS hergestellt. Durch die Verknüpfung kann der automatisierte Testfall wie ein manuel- ler Testfall verwaltet, ausgeführt und aus- gewertet werden. Der Fachtester hat zudem den Vorteil, dass er bei Problemen mit dem automatisierten Test sofort auf das Visual Studio Projekt rückschließen kann, was gerade bei der Abstimmung mit dem ver- antwortlichen Entwickler eine Menge Zeit sparen kann. Eine weitere Möglichkeit Ressourcen zu schonen, ist die Möglichkeit der Ermittlung von empfohlenen Tests auf Basis von geän- derten Codezeilen (MTM: Recommended Tests).Abbildung 4 - Test Case Work Item Ausführung von Tests Nachdem die Testfälle spezifiziert sind undTestfälle?“. Die Navigation zwischen „Shared Step“ lässt sich in ein oder mehre- sich im Zustand „Ready“ befinden, wechselnAnforderungen und Testfällen ermöglicht re Testfälle einbinden. Ein typisches An - wir im MTM auf das Tab „Test“. Im Taballen Beteiligten, den Kontext sowohl aus wendungsbeispiel ist der Login- Dialog bei „Test“ finden wir erneut unsere Testsuitender Entwicklungs- und Testperspektive bes- einer Anwendung. aus der Planungsphase. In der aktuellenser zu verstehen und so schlussendlich bes- Der zweite Optimierungspunkt wäre die Ansicht haben Sie die Möglichkeit auf densere Software durch bessere Kommunika- Parametrisierung unseres Testfalles. Durch Testernamen, sowie die zu testendetion zu erstellen. das Anfügen eines @ - Zeichens können Testkonfiguration zu filtern. Beispiele für Die zuvor angesprochenen Testfälle sind Parameter sowohl für den Testschritt als Testkonfigurationen sind Betriebssystemim TFS auch nur Work Items. Ein Beispiel für auch für das erwartete Ergebnis erzeugt oder Sprache. Ein Testfall kann einer oderein 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 Abbildung 5 - Testrunner 3 www.objektspektrum.de
  • 4. Online-Themenspecial Testing 2010 advertorialmehreren 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 der Abbildung 6 - RichbugProzess sogar soweit, dass an den Bug aucheine Verknüpfung zur passenden Testum- Neben der Erstellung von Bugs kann der interessanten Testschritten wird als „Fastgebung angefügt wird. Auf diese Weise Testrunner auch alle Aktionen auf der Forward Testing“ (vgl. (6)) bezeichnet. Dieerzeugte Bugs haben drastische Vorteile Oberfläche verfolgen und bei einem späte- so erzeugten Aufnahmen heißen im MTMgegenüber Bugs aus klassischen Bug ren Regressionstest erneut abspielen. Das ActionLogs und werden ebenfalls proTracking Systemen: Sie entlasten den erneute Nachspielen von Aktionen bis zu Testfall Work Item im TFS zentral gespei-Tester, 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. Abbildung 7 - Test ResultsOnline-Themenspecial Testing 2010 4
  • 5. advertorial zeigt Abbildung 8. Sie haben über das Reporting aber auch die Möglichkeit, einfa- chere Auswertungen mit reinem Testfokus wie z. B. Testfortschrittsanalysen zu erstellen. Fazit Mit der neuen Visual Studio 2010 Familie hat es Microsoft geschafft, auch den Aspekt Testprozesse in die durchgängige Informationskette im Team Foundation Server zu integrieren. Testartefakte sind jetzt nicht mehr separat in eigenen Werkzeugen abgelegt, sondern stehen direkt in einer Beziehung zu Anforderungen, Bugs, Quellcode und Build-Prozessen. Diese tiefe Integration ermöglicht eine nie da gewesene direkte Zusammenarbeit und Kommunika- tion zwischen Entwicklung und QS. Des Weiteren entlasten die neuen Test- werkzeuge den Tester durch einen hohen Automatisierungsgrad bei der Kommuni-Abbildung 8 - Requirements Overview Report kation mit dem Entwickler, indem die rele- vanten technischen Daten für den Entwickler im Hintergrund an den Entwickler extrahierbar sind. Diese sindchert. Damit der MTM Aktionen auf den Auswertung von auch für einen Fachanwender relativ einfachOberflächen verfolgen kann, müssen die Testergebnissen nachvollziehbar. Eine weitere Entlastung fürControls von Programmen entweder den Alle Daten, welche sowohl bei der Planung alle Beteiligten lässt sich durch dieStandard Microsoft Active Accessibility und Ausführung von Tests entstanden sind, Einführung von automatisierten Ober-(kurz:MSAA) (vgl. (7))) oder Microsoft UI werden stets im TFS zentral abgelegt. Durch flächentests (TFS: CodedUI Tests) (vgl. (10))Automation (kurz: UIA (vgl. (8))) genügen. die zentrale Speicherung können alle Betei- um das Testen in virtuellen TestumgebungenAktuelle Microsoft .NET Frameworks ligte die Ergebnisse von einzelnen Testläufen (TFS: Lab Management) (vgl. (11) ) erzielen.Technologien wie z. B. WinForms 2.0 und über den MTM einsehen (siehe Abbildung 7). Der Einsatz vom Lab Management undneuer, WPF 3.0 und neuer und Webseiten Aufgrund der Verknüpfung von Anfor- Coded UI Tests ist nicht inhaltlicher Fokus(HTML/AJAX) im IE 8 werden bereits derungen und Testfällen ist des Weiteren die dieses Artikels.vollständig unterstützt (vgl. (9)). Weitere Auswertung von Testergebnissen im Kontext Zudem ist hervorzuheben, dass trotz derProgramme und Technologien, wie von Anforderungen möglich, wodurch sich Integration jeder Anwender seine gewohn-Silverlight oder Webanwendungen im Aussagen bzgl. der Qualität von einzelnen ten bzw. speziellen Werkzeuge nutzen kannFirefox testen, werden in nächster Zeit Anforderungen treffen lassen. Ein Beispiel für und alle dennoch über den zentralen TFSebenfalls möglich sein. eine solche anforderungsbasierte Auswertung zusammenarbeiten können. ■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) 5 www.objektspektrum.de