Ein Dialog unter Fremden:Testautomatisierung in der PraxisMontagmorgen 8:15 Uhr, das E-Mail-Programm zeigt den Empfang einer neuen Mail. Absender: Unbekannt. Betreff:Testautomatisierung. Stellen Sie sich vor, Sie sind der Empfänger dieser Mail. Die Situation könnte nicht skurriler sein, denn IhrChef hat Sie erst vor wenigen Tagen mit einem neuen strategischen Projekt betraut. Sie als langjähriger Mitarbeiter sollenTestautomatisierung in alten und neuen Softwareprojekten des Unternehmens einführen bzw. verbessern. Das Problem: Sie ken-nen das fachliche Umfeld, sind aber Einsteiger in der Testautomatisierung und möchten nichts falsch machen. Der Artikel doku-mentiert den Verlauf einer imaginären Unterhaltung zwischen dem unbekannten, erfahrenen E-Mail-Absender und Ihnen, demFragesteller. Im Verlauf des Gesprächs diskutieren Sie beide die Grenzen, Chancen und Erfahrungen bei der Umsetzung vonTestautomatisierung im Alltagseinsatz. Die Schwerpunkte liegen dabei auf Arbeitsteilung im Team, dem richtigen Test- undAufwandsmix bei Legacy Software und Neuentwicklungen sowie Anforderungen an Programm- und Testcode.

würde ich mich freuen, mit Ihnen dasThema zu erörtern.Als Berater unterstütze ich viele Kunden beider Umsetzung und Planung vonTestautomatisierung. Durch verschiedeneKundenprojekte, Blogartikel, Tweets undFachzeitschriften konnte ich verschiedeneTrends im Softwaretest bereich beobachten.In den Medien wurde in den vergangenenJahren viel zum Thema agile Prozesse unddamit oft einhergehend Unit-Testing veröf-fentlicht. Testautomati sierung wird dabei oftmit Unit-Testing gleichgesetzt. Aus meinerSichtweise ist dies jedoch zu kurz gedacht. Was verstehen Sie unter Testauto mati -sierung? Was gehört aus Ihrer Sichtweisedazu?

Mit freundlichen GrüßenDer Unbekannte

Nach dieser Mail war ich erstmal sehrüberrascht und verwirrt zu gleich. Es istschon ein großer Zufall, dass ich michwirklich gleichzeitig mit dem Themabeschäftige. Die erste Frage ist äußerstinteressant: Was ist Testautomatisierung?

Arbeit mit dem MTM verläuft bis jetzt gut.Wir können schnell und einfach unsereTestfälle erfassen, die Tests ausführen unddie Ergebnisse und Testfälle mit denBeteiligten teilen. Im Rahmen unsererersten Gehversuche haben wir mit MTMdie Testausführungen aufgezeichnet undbeim wiederholten Test abgespielt und soetwas Zeit gespart. Für einfache Schritt -folgen hat dies recht gut funktioniert undso beim Management den Wunsch nachmehr Automatisierung geweckt.

Testautomatisierung*Bling* *Sie haben eine neue E-Mail*Absender: unbekannt@gmx.netEmpfänger: tester@gmail.com Datum: 01.08.2013 8:15Betreff: TestautomatisierungNachricht:Hallo Fremder,Sie kennen mich nicht. Ich hatte gerade dasBedürfnis, mich mit einem Fremden aus-tauschen zu wollen. Mein Thema ist aberschon ungewöhnlich – Testauto -matisierung. Beschäftigen Sie sich zufälligauch mit diesem Thema? Wenn ja, dann

Das bin ichSie werden es nicht glauben, aber lassen Siemich am Anfang meiner Reise zur Test -automatisierung beginnen. Vor wenigenTagen habe ich relativ überraschend vonmeinem Vorgesetzten die Aufgabe bekom-men, das Thema Testautomatisierung fürbereits existierende Produkte und Neu -entwicklungen aus unserem Haus zubegleiten. In meiner aktuellen Positionarbeite ich als Tester bereits seit mehr als 5Jahren. Als Tester kenne ich deshalb meinfachliches Umfeld gut, schreibe ohne großeMühe meine Testfälle und organisiere dieseeffizient in Testplänen. Zu Beginn habenwir unsere Testpläne noch in Excel organi-siert. Sie können sich sicherlich vorstellen,dass das eine Menge Arbeit verursacht hat.In den letzten drei Jahren haben wir unse-ren Testmanagementprozess von Excel aufden Microsoft Team Foundation Server(TFS) und den dazugehörigen MicrosoftTest Manager (MTM) umgestellt. Für unswar das eigentlich keine große Umge -wöhnung, haben doch unsere Entwicklerund Projektmanager den TFS schonwesentlich länger im Einsatz. Die tägliche

der au tor

Nico Orschel

(nico.orschel@aitgmbh.de)ist Software Process Consultant, Autor und Referent im Umfeld MicrosoftALM bei der AIT GmbH & Co. KG Stuttgart und wurde von Microsoft als MostValuable Professional (MVP) für Visual Studio ALM ausgezeichnet. Er hilftUnternehmen, auf Basis von Microsoft Visual Studio Team Foundation Servereffizienter Software zu entwickeln und zu testen und so ein höheresQualitätsniveau bei kürzeren Release-Zyklen zu erreichen.

1 www.objektspektrum.de

advertorial

Was gehört eigentlich alles dazu?Testautomatisierung würde ich definierenals die Automation von Testaktivitäten. DieAutomation umfasst dabei nicht nur dasautomatische Abarbeiten von Schritten,sondern auch die Prüfung des Testergeb -nisses. Die Prüfung des Testergebnisses ent-scheidet über Bestehen oder Fehlschlagender Tests.

Vor ein paar Wochen habe ich mir zurVorbereitung auf meine neue Aufgabe einBuch mit dem Titel „Agile Testing“ (vgl.[Cri08]) gekauft. Im Buch wird ein interes-santes Konzept zur Strukturierung vonTestarten vorgestellt, die Agile TestingQuadrants (siehe Abbildung 1).

Das Konzept gruppiert grundlegend dieTestarten nach verschiedenen Dimensio -nen: technologieorientiertes, teamorientier-tes, produktorientiertes und fachorientier-tes Testen. Aus der Kombination derDimensionen ergeben sich vier Sektoren(von I links unten bis IV rechts unten).

Das Thema Unit-Testing aus der Maildes Unbekannten deckt also nur einenBruchteil eines umfassenden Testprozessesab (siehe Sektor I). Betrachte ich unsereneigenen Testprozess, dann fällt auf, dassunsere Testaktivitäten primär im Quadran -ten III angesiedelt sind.

Absender: tester@gmail.comEmpfänger: unbekannt@gmx.netDatum: 01.08.2013 19:01Betreff: Re: Testautomatisierung

Nachricht:Hallo Unbekannter, Ihre Mail hat mich sehr überrascht. Es istschon ein großer Zufall, dass ich mich gera-de ebenfalls mit dem Thema Testauto -matisierung in meinem Job befasse. Das Thema Testautomatisierung scheintmir inhaltlich sehr breit zu sein. Generellverstehe ich unter Test automatisierung dieAutomatisierung von Testaktivitäten undPrüfung der Ergebnisse. Um den Überblick über das breite Feld derTestarten zu erhalten und konkretTestarten inhaltlich für einzelne Pro jekte zuplanen, verwende ich die „Agile TestingQuadrants“ von Brian Marrick (vgl.[Cri08]). Aus dem Kon zept habe ich fürmich Komponenten tests, funktionale Tests,User Acceptance Testing, Szenarien sowiePerformance- und Load-Testing als sehrgute Bereiche für die Testautomati sierungabgeleitet. Wenn ich die vielen Bereiche sehe, dannhabe ich die Befürchtung, dass kleineEntwicklungs- und Testteams überfordertsein könnten. Wie verteilen und organisieren Sie dieArbeit in Ihren Teams?

Viele GrüßeDer Tester

TeammixMittlerweile ist wieder ein Tag vergangenund meine Gedanken drehen sich immer

noch um die Organisation meines Teams.Wie verteile ich die Arbeit auf die verschie-denen Personen? Wer kann was leisten?Wer sollte was leisten können?

Aktuell setzt sich das Team nur aus„klassischen“ Testern zusammen. Testenbedeutet hier vereinfacht dargestellt,Testfälle erstellen, Testfälle ausführen undErgebnisse kommunizieren. Mit dem neuenThema Testautomatisierung kommen aberplötzlich Code, Unit-Tests, Oberflächen -tests mit Visual Studio CodedUI, Schnitt - stellentests oder Performancetests auf dasTeam zu.

Absender: unbekannt@gmx.netEmpfänger: tester@gmail.com Datum: 02.08.2013 8:43Betreff: Re: Re: TestautomatisierungNachricht:Hallo Tester,Es freut mich, wieder von Ihnen zu hören.Das Thema Teamorganisation ist aus mei-ner Erfahrung spannend, höchst individuellund unterbewertet zugleich. Wie sich bereits in den vorherigen E-Mailssicherlich herausgestellt hat, ist dieTestautomatisierung zu großen Teilen vonSoftwareentwicklungs aktivitäten geprägt.Kurz gesagt: „Eine Softwareentwicklung inder Softwareentwicklung.“ Es wird Quell -code ge schrieben, welcher wiederum Codetestet. Aus meiner Sichtweise ergibt sichdaraus, dass für eine langfristig erfolgrei-che Testautomatisierung gute bis sehr guteEntwicklungsfähigkeiten notwendig sind.Es wird für diese Aufgabe eigentlich derklassische Entwickler benötigt. In derRealität finden aber Entwickler Software -testen nicht beson ders attraktiv. Die enor-me Bedeutung dieser Aufgabe zeigen z. B.spezielle Jobrollen bei den großen IT-Giganten (Google, Microsoft, etc.). Diesegroßen Firmen nennen diese Rolle bei-spielsweise „Engineers for Testing“. DieseMitarbeiter haben eine Ausbildung zumEntwickler, welche um die Testexpertiseerweitert wird, sodass sich diese Expertensehr elegant zwischen den Welten der Testerund der Entwickler bewegen können.Nun stellt sich die Frage: Brauche ich jetztkeine klassischen Tester mehr oder mussich Tester zu Programmierern umschulen?Tester haben ja aufgrund des fachlichenHintergrundes selten mit Visual Studio,C++, C# etc. zu tun. Meine Antwort heißthier klar: nein. Tester haben eine sehr wich-tige Aufgabe bei Testautomati sierungs -projekten. Sie haben hier den großen

2Online-Themenspecial Testing 2013

Online-Themenspecial Testing 2013 advertorial

Abb. 1: Agile Testing-Quadranten.

zu beachten, dass Fehler im Testcode oftnach Änderung und anschließenderAusführung erst zur Laufzeit feststellbarsind. Analysen gestalten sich entsprechendaufwändiger. Bedeutet das nun, alle Auf -wände auf Unit-Testing zu konzentrieren?Meiner Meinung nach ist dem nicht so; dieoberen Teststufen ergänzen Tests um ande-re inhaltliche Schwerpunkte. Ohne die obe-ren Schichten könnten z. B. keine End-To-End-Tests durchgeführt werden. Werdenverschiedene Komponenten zusammen inKombination getestet, dann können dieseein anderes Verhalten aufweisen. DasGleiche gilt, wenn sich das Verhalten durchdie Kombination von unterschiedlichenBenutzeraktionen verändert. Als Ergebnisbedeutet dies, dass die oberen Teststufeneine notwendige Ergänzung darstellen.

Absender: tester@gmail.comEmpfänger: unbekannt@gmx.netDatum: 03.08.2013 19:01Betreff: Re: Re: Re: TestautomatisierungNachricht:Hallo Unbekannter, Vielen Dank für den Hinweis auf das TestAutomation-Pyramidenkonzept. Eine drei-teilige Einteilung der Testarten und die pro-zentuale Gewichtung sind ein leicht ver-ständliches Konzept zur Planung einerganzheitlichen Testauto mationsstrategie.Ich werde dies bei meinem Testplan be -rück sichtigen. Für mich ergibt sich daraus die Anfor -derung, dass ich in meine Teststrategie aufjeden Fall die Entwicklerperspektive einbe-ziehen muss (Unit- und Kompo nenten -tests). Zusätzlich zu den unteren Teststufen solltenwir vom Testteam die oberen Test stufenadressieren. In Anlehnung an die vorletzte E-Mail werde ich einen neuen Kollegen mitEntwicklungs hintergrund als Teamunterstüt -zung suchen. Wir wollen schließlich einenachhaltige Test auto matisierung aufbauen. Es ist an dieser Stelle wieder interessant zusehen, wie unsere aktuelle Testpraxis ist.Wenn ich aus der Vogelperspektive aufunseren aktuellen Testprozess schaue, dannkonzentrieren sich aktuelle Aufwände aufmanuelles oberflächenbasierendes Testen.Ich denke, hier haben wir viel Opti -mierungspotenzial im Hinblick auf die TestAutomation-Pyramide (aktueller Fokus UI-Testing) und die Agile Testing-Quadranten(aktueller Fokus: Quadrant III). UnserTesten muss hier breiter aufgestellt undrepriorisiert werden.

Gefolgt werden sie von den Komponen -tenintegrationstests mit ca. 20 % amGesamtaufwand und den UI-Tests mit denverbleibenden ca. 10 %. Die interessanteFrage ist hier: Warum haben Unit-Testseinen solchen dominanten Anteil gegenü-ber den UI-Tests? Brauche ich überhauptdie „höheren“ Teststufen? Unit-Tests undKomponententests setzen ein hohes inter-nes Wissen über die zu testende Softwarevoraus, d. h., der Tester benötigt Wissenüber Schnittstellen bzw. Programmcode.Diese Testmethoden haben generell denVorteil, dass bei sich ändernden Schnitt -stellen oder Buildprozessen Werkzeuge wiez. B. Visual Studio frühzeitig auf potenziel-le Fehler und notwendige Anpassungenhinweisen können. Werden dadurch Fehlerfrüher erkannt und notwendige Anpas -sungen zeitnah durchgeführt, so führt diesdirekt zu reduzierten Testpflegeaufwänden.Reduzierte Testaufwände bedeuten alsFolge weniger Kosten, personelle Auf -wände und frühere Liefertermine.

Die Herausforderung beim Testen in denhöheren Teststufen liegt meistens in zweiPunkten: erstens wird eine lauffähigeSoftware getestet und zweitens verfügt diezu testende Software über umfangreicheexterne Abhängigkeiten (z. B. Daten ban -ken, Webserver). Das notwendige Wissenüber Interna wie Klassenstrukturen oderOrganisation und Quellcode nimmt imVerhältnis zu den „unteren“ Teststufen ab.Aufgrund der Notwendigkeit einer laufen-den Software ist das automatisierte Testenerst mit einem Zeitversatz möglich. Diehöheren Schichten müssen für aufwands-optimiertes Testen eine hohe Stabilitätbesitzen. Bezüglich des Testcodes gilt hier

Vorteil, dass sie unbelastet von Technikund Entwick lung sind. Zu testen und fach-liches Feedback im Kontext des Testauto -mati sierungsprozesses zu geben ist deshalbneutraler möglich. Die Testfälle können alsErgänzung zu den Anforderungen aufge-fasst werden. Sie bilden damit ein wichtigesFundament. Viele Entwickler verfallen beiTestautomatisierung gerne dem techni-schen Interesse, d. h. Auto matisieren um zuAutomatisieren, ohne konkrete Planungund aus konkreten Testfällen abgeleitetenAnforderungen. Ein guter Tester kann hierfür eine gesunde Balance aus Technik,Aufwand und Nutzen sorgen. Zum Schluss der heutigen Mail eine weite-re Frage an Sie. Haben Sie sich schonGedanken über den Umfang der einzelnenTestaktivitäten gemacht? Wenn nein, dannmöchte ich Ihnen gerne die TestAutomation-Pyramide von Mike Cohn mitauf den Weg geben (vgl. [Mou]).

Mit freundlichen GrüßenDer Unbekannte

TestmixDer Unbekannte hat Recht. Aktuell habeich mir nur über das Was und Wer, abernicht über das Wie viel Gedanken gemacht.Auf Grundlage des Stichwortes TestAutomation-Pyramide (siehe Abbildung 2)habe ich eine Internet-Recherche durchge-führt. Die Test Automation-Pyramide teiltdie Tests für die Planung von Testauf -wänden (bezogen auf Standardsoftware) indrei Klassen ein, Unit-, Komponenten- undoberflächenbasierende Tests. Unit-Testingkommt dabei mit ca. 70 % am gesamtenTestaufwand eine besondere Bedeutung zu.

advertorial

3 www.objektspektrum.de

Abb. 2: Test Automation-Pyramide.

Haben Sie zufällig noch Tipps zumUmgang mit „alten“ und „neuen“ Pro -jekten im Zusammenhang mit Test -automatisierung?

Viele GrüßeDer Tester

In meiner Selbstvorstellung habe ich bereitsgeschrieben, dass ich demnächst sowohl dieTestautomatisierung für alte als auch neueProjekte begleiten soll. In der Vergan -genheit hat mein Arbeitgeber bereits meh-rere kleine Versuche unternommen,Testautomatisierung einzuführen. Es wur-de oft probiert, wie in der Test Automa -tion-Pyramide vorgestellt, Unit-Tests alsdas Fundament zu verankern. Es stellt sichjetzt für mich die Frage, ob dies wirklichimmer der richtige Weg für eine wirtschaft-liche Testautomatisierung ist.

Legacy-Software undNeuentwicklungenAbsender: unbekannt@gmx.netEmpfänger: tester@gmail.comDatum: 05.08.2013 14:53Betreff: Re: Re: Re: Re:Testauto mati sierungNachricht: Hallo Tester, Ich möchte gerne Ihre erste Frage aufgrei-fen. Im Alltag beobachte ich sehr vieleTeams, welche Ihre gesamten Anstren -gungen auf Unit-Tests konzentrieren. DieseStrategie ist aus meiner Sichtweise erstmalgrundlegend für Neuentwicklungen ver-nünftig. Vorteilhaft ist hierbei, dass Teams in den frü-hen Phasen die interne Software architekturder jeweiligen Anwen dungen fürTestautomatisierung optimieren können.Beispiele sind im .NET-Umfeld Schnitt -stellen oder Kapse lung von Funk tionalitätenin Modulen. Hier sieht man gut, dass dieEnt wicklung bereits sehr früh denGrundstein für das spätere Testfun da mentlegt. An dieser Stelle kann ich Ihnen denEinsatz eines erfahrenen Software archi -tekten empfehlen. Früh zeitig Architek tur -fehler erkennen und beheben spart späterZeit, Geld und Nerven. Ein Review durcheinen Dienstleister ist ebenfalls eine interes-sante Alternative. Ein unabhängiger Blickauf die Software kann bisher nicht erkannteSchwachstellen aufdecken und neue Ideen indas Team bringen. Einen guten Einstieg in das ThemaOptimierung bietet „The Art of Unit

Testing“ (vgl. [Art]). Das Buch eignet sichnicht nur, wie der Titel suggeriert, für Unit-Testing, sondern auch für Integrationstests.Die bisherigen Hinweise gelten primär fürNeuentwicklungen, aber das bedeutetnicht, dass dies auch zwingend für andereProjekttypen optimal ist. Bei derEinführung von Testautomatisierung für„historische“ Projekte sehe ich dieSituation ein wenig anders. Ein Großteilder historischen Projekte ist vor mehr als10 Jahren entstanden. Bis zum heutigenTag haben diese Produkte bereits sehr vieleAnpassungen und Ergänzungen erfahren.Eine Grund voraus setzung für eine auf-wandsoptimierte Testautomatisierung wur-de dabei aber leider sehr selten beachtet:Die Software muss auch eine testoptimier-te Softwarearchitektur aufweisen. Einemodulare Bauweise oder Schnittstellen sindoft nur unzureichend umgesetzt. Fehlenbereits diese essenziellen Dinge, so wirdeine spätere Testautomati sierung technischsehr schwierig und verursacht hohe Kosten. An dieser Stelle gilt es, eine Ent scheidung zufällen. Entweder Sie bereinigen aufwändigdie Schwächen in der Architektur oder Sienutzen je nach Technologie Hilfswerkzeugewie Visual Studio Fakes (vgl. [Msd]) oderType mock Isolator (vgl. [Typ]), umAbhängigkeiten in der Architektur zu min-dest für die Tests aufzulösen. Eine kleineWarnung zum Einsatz: Werk zeuge dieserKategorie ermöglichen es, sehr elegant „un-testbaren“ Code für Unit- und Integrations -tests zugänglich zu machen. Die Gefahr lau-ert aber bei dem nicht zu unterschätzendenAuf wand für Pflege und Wartung der Testsund des damit verbundenen Isolations codes.Diese Werkzeuge dürfen deshalb nur alskurzfristige Übergangslösung betrachtetwerden. Langfristig sollten Sie eine opti-mierte Softwarearchi tektur anstreben. Für historische Projekte hat sich als guterStartpunkt für Testautomati sierungs -projekte die Konzentration auf die oberenTeststufen, System- und UI-Tests, heraus-gestellt. Service- und UI-Testing setzen einenicht so tief greifende Isolation zwischender zu testenden Soft ware und den exter-nen Abhängig keiten voraus. Das Ziel isthier, die Komplexität und den Aufwand fürdie Erstellung von automatisierten Testsaufgrund von komplexen Isolations codeszu reduzieren. Ähnliches gilt, wenn not-wendige Architektur änderungen verscho-ben werden müssen. Durch den Aufbau dieser speziellenTestbasis werden zunächst die Basis -

funktionen der zu testenden Software abge-deckt. Das Leitmotiv ist hier: BesserIntegrations- und UI-Tests als keine auto-matisierten Tests. Diese ersten automati-sierten Tests bilden später wieder dasSicherheitsnetz für anstehende Refactoring-und Optimierungs maßnahmen in denFolgeschritten. Ein Nebenziel dieserStrategie ist, sich nicht auf sehr aufwändigeUnit-Tests ohne Mehrwert zu konzentrie-ren.Eine letzte Anmerkung zu Ober -flächentests: Auch bei dieser speziellenTestkategorie müssen Sie Ihre Software imVorfeld optimieren. Viele am Markt eta-blierte Testprogramme (Microsoft VisualStudio CodedUI / Ranorex / etc.) setzenUI-Schnittstellen wie MSAA (MicrosoftActive Accessibility) bzw. UIA (MicrosoftUI Automation) in Ihrer Software voraus(vgl. [Mic]). Ohne Optimierung investierenSie auch hier viel Aufwand in eine instabileTestautomatisierung. Ich hoffe, die Tipps können Sie vor folge-schweren teuren Entscheidungen bewah-ren.

Mit freundlichen GrüßenDer Unbekannte

FazitDie letzte E-Mail vom Unbekannten warschon sehr umfangreich und hilfreich. DasThema Testautomatisierung ist sowohl ausder technischen als auch prozessualen Pers -pektive kein Selbstläufer ohne Aufwand.Die Diskussion hat mir ermöglicht, neueIdeen und Denkanstöße für eine erfolgrei-che Testautomatisierung mitzunehmen.Meine Woche der Testautomatisierungwerde ich in einer E-Mail der Kategorie„Lessons learned“ abschließen.

Absender: tester@gmail.comEmpfänger: unbekannt@gmx.netDatum: 07.08.2013 17:05Betreff: Re: Re: Re: Re: Re:TestautomatisierungNachricht: Hallo Unbekannter,

Vielen Dank für Ihre wertvolle Zeit und dieTipps der letzten Tage. Ohne die intensive Diskussion wäre ich dasThema Testautomatisierung sicherlichanders angegangen. Ich möchte gerne zumAbschluss der Woche die wichtigstenPunkte nochmals zusam men fassen: Testautomatisierung ist ein Zusam men spiel

4Online-Themenspecial Testing 2013

Online-Themenspecial Testing 2013 advertorial

sind extrem erfolgskritisch und könnennicht durch Werkzeuge ersetzt werden.Werkzeuge können nur unterstützen, abernicht testen.

Vielen Dank und ein schönes Wochen endewünschtIhr Tester ■

Anwendungs code für die Testautomati -sierung optimiert werden.Zu guter Letzt nehme ich mit: Eine nach-haltige Testautomatisierung bindet Auf -wand auf allen Ebenen. Testauto -matisierung macht sich nicht von allein,auch wenn Werkzeuge ein anderes Gefühlvermitteln. Planung, Wissen und Menschen

aus Entwicklern und Testern. Das Zu -sammenspiel der individuellen Stär ken(Fokus der Entwickler auf Code und derTester auf Fachlichkeit) sorgt für ein nach-haltiges Fundament und damit besserenCode in Tests und An wendung. Der zweite Punkt ist, dass Testauto -matisierung mehr als Unit-Testing ist. Einegute Testautomatisierung setzt, wie beimTeam, das Zusammenspiel von mehrenTestmethoden voraus. Die richtige Aus -wahl und Priorisierung schafft aus derProzessperspektive das Funda ment für diegesamten Anstrengungen und entscheidetüber langfristigen Erfolg oder Misserfolg. Als dritten wichtigen Punkt nehme ich mit,dass für Legacy Software („historischeSoftware“) andere Spielregeln gelten. Es isthier soft sinnvoll, dass bei der TestAutomation-Pyramide mit den oberenTeststufen begonnen wird. Ziel ist hier,Aufwand und Nutzen in ein wirtschaftlichesVerhältnis zu setzen. Unit-Tests können hiereinen nicht zu rechtfertigenden Aufwandbedeuten. Lang fristig sollte hier der

advertorial

5 www.objektspektrum.de

Referenzen

[Art] The Art of Unit Testing, siehe http://artofunittesting.com/.

[Cri08] L. Crispin, J. Gregory, Agile Testing: A Practical Guide for Testers and Agile Teams,

Addison Wesley, 2008.

[Mic] Engineering Software for Accessibility eBook, siehe http://download.microsoft.com/downlo-

ad/5/0/1/501FF941-E93D-423F-868B-C7BB2EC08C56/engineering_for_accessibility_eBook.pdf.

[Mou] The Forgotten Layer of the Test Automation Pyramid, siehe

http://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid.

[Msd] Isolating Code Under Test with Microsoft Fakes, siehe

http://msdn.microsoft.com/en-us/library/hh549175.aspx.

[Typ] Typemock Isolator, siehe http://www.typemock.com/isolator-product-page.