BOOKLET SOFTWAREQUALITÄT IN AGILEN PROJEKTEN Copyright 2016 bbv Software Services AG
AGILES TESTEN QUALITÄTSSICHERUNG IN AGILEN PROJEKTEN PROFITIEREN SIE VON UNSERER ERFAHRUNG! INHALT Kontakt Schweiz bbv Software Services AG Blumenrain 10 6002 Luzern Telefon: +41 41 429 01 11 E-Mail: info@bbv.ch Kontakt Deutschland bbv Software Services GmbH Agnes-Pockels-Bogen 1 80992 München Telefon: +49 89 452 438 30 E-Mail: info@bbv.eu Der Inhalt dieses Booklets wurde mit Sorgfalt und nach bestem Gewissen erstellt. Eine Gewähr für die Aktualität, Vollständigkeit und Richtigkeit des Inhalts kann jedoch nicht übernommen werden. Eine Haftung (einschliesslich Fahrlässigkeit) für Schäden oder Folgeschäden, die sich aus der Anwendung des Inhalts dieses Booklets ergeben, wird nicht übernommen. 1 Einleitung 5 2 Agile Softwareentwicklung 7 3 Rollen und Verantwortlichkeiten 9 4 Automatisierung 14 4.1 Test-Driven Development (TDD), Test-First 15 4.2 Acceptance-Test-Driven Development (ATDD) 17 4.3 Behaviour-Driven Development (BDD) 17 4.4 Data-Driven Testing (DDT) / Keyword-Driven Testing (KDT) 18 4.5 Model-Driven Software Development (MDSD) 19 4.6 Automatisierungsstrategie 20 4.7 Unit-/Komponententest 21 4.8 Acceptance-Test/Api-Layer-Tests 21 4.9 Systemtest/Gui-Test 21 4.10 Exploratives Testen 22 4.11 Beispiele 23 5 Testplanung 24 5.1 Qualitätsziele 26 5.2 Teststrategie 27 5.3 Testplan 28 5.4 Teststatusreport 29 6 Profil des agilen Testers 30 7 Testaktivitäten in einer Iteration 32 7.1 Release-Planung und Pre-Planning 33 7.2 Iterationsplanung 34 7.3 Umsetzung 35 7.4 The End Game 35 7.5 User-Akzeptanz-Test (UAT) 36 2 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2015, BBV SOFTWARE SERVICES AG 3
AGILES TESTEN QUALITÄTSSICHERUNG IN AGILEN PROJEKTEN 1 EINLEITUNG 7.6 Feedback 37 8 Erfolgsfaktoren 38 8.1 Das ganze Team ist verantwortlich 39 8.2 Sammeln und liefern Sie Feedback 39 8.3 Automatisieren Sie Regressionstests 39 8.4 Behalten Sie den Überblick 40 8.5 Führen Sie bei Bedarf Ruhesprints ein 40 8.6 Nutzen Sie agile Kernpraktiken 40 8.7 Binden Sie den Kunden mit ein 41 8.8 Seien Sie als agiler Tester frühzeitig dabei 41 9 Anhang 42 9.1 Autor 43 9.2 Referenzen 43 Software ist in unserer heutigen Gesellschaft nicht mehr wegzudenken. Verkürztes Time-to-Market bei hoher Softwarequalität sind heute entscheidende Erfolgsfaktoren. Dies hat erhebliche Auswirkungen auf die Softwareentwicklung: Heutzutage wird die Meinung vertreten, dass sequenzielle (nicht agile) Modelle, wie z. B. das Wasserfallmodell oder das V-Modell, durch ihre fixen, getrennten Phasen nicht flexibel genug oder zu schwergewichtig seien, um bei einer Neuentwicklung im dynamischen Markt standzuhalten. Iterative (halb agile) Modelle, wie z. B. das Spiralmodell oder Rational Unified Process (RUP), verfeinern und ergänzen schrittweise die grobe Ausgestaltung des Gesamtsystems durch kurze Wiederholungen von Coding- und Testphasen. Oft verzichten Unternehmen jedoch bewusst und gänzlich auf starre Phasen. Mittlerweile ist ein eindeutiger Trend zu rein agilen Vorgehensmodellen wie Scrum zu verzeichnen. Der Auftraggeber erhält regelmässig in kurzen Zyklen lauffähige und getestete «Softwarebausteine», bewertet diese und kann situationsabhängig Anpassungen vornehmen lassen. Somit kann er binnen kürzester Zeit auf Marktveränderungen reagieren oder sich bewusst Wettbewerbsvorteile verschaffen. 4 COPYRIGHT 2015, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 5
Agile Entwicklungsprojekte verändern jedoch auch das Testen von Softwareprodukten meist als «Agiles Testen» bezeichnet. Der Fokus liegt dabei in der Einbindung von Testern in agile Entwicklungsprozesse unter Beachtung des agilen Manifests und der Anwendung agiler Prinzipien auf das Testen, wie schnelles Feedback, hoher Automatisierungsgrad, Auflösung starrer Teststufen, enge Zusammenarbeit in selbst organisierten Teams und Vermeidung von Overhead. Das agile Testen erfordert ein «Umdenken» bisheriger «klassischer» Tester, weil die Verantwortung aller Testaktivitäten nun auf das gesamte agile Team verteilt wird. 2 AGILE SOFTWARE- ENTWICKLUNG Ziel der agilen Softwareentwicklung ist es, sich mehr auf die zu erreichenden Ergebnisse (den «Outcome») der Softwareentwicklung zu konzentrieren. Frühzeitig soll für den Auftraggeber ein maximaler wirtschaftlicher Mehrwert (Business Value) erzielt werden. Änderungen sollen ohne grossen zeitlichen und formalen Aufwand realisiert werden können. Doch wie ist dies zu erreichen? Insbesondere bei Tests, die häufig wiederholt werden müssen, wird Testautomation in Form von Regressionstests inklusive nicht funktionaler Tests angeraten, um die Softwarequalität zu sichern. So können Abweichungen in der Systemstabilität frühzeitig erkannt, Testzeiten verkürzt, Tests beliebig oft wiederholt und durchgängig (24/7) durchgeführt werden. Dabei reicht es nicht aus, dass Entwickler nur automatisierte Tests durchführen, um die Qualität eines Softwaresystems sicherzustellen. Moderne agile Entwicklungsteams führen neben Unit-Tests auch Akzeptanztests aus und ergänzen diese durch explorative Tests. Dies erfordert den sinnvollen Einsatz geeigneter Testverfahren, eine gute Test-/Iterations- und Release-Planung und hohe Skills des agilen Testers. Mit diesem Booklet möchte ich Ihnen kurz die wesentlichen Highlights und Erfolgsfaktoren des Testens in agilen Projekten am Beispiel des Vorgehensmodells Scrum näherbringen. Zunächst werden die Anforderungen in Form von User Stories priorisiert und im Product Backlog verwaltet. Alle Stories werden vom Team analysiert, in Tasks aufgeteilt und bezüglich ihrer Aufwände geschätzt. Das Team entwickelt nun in in kurzen Iterationszyklen von zwei bis vier Wochen neue oder geänderte Funktionalitäten und legt diese dem Auftraggeber als Ergebnis vor. Agile Engineering-Praktiken wie Test-Driven Development (TDD), Extreme Programming (XP) und Continuous Integration (CI) unterstützen dieses Vorgehen, sodass durch frühe Releases von Kernfunktionalität ein schneller Return of Investment (ROI) erreicht werden kann. 6 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 7
Sprint Planning Sprint Retrospective 3 ROLLEN UND VERANTWORTLICHKEITEN Sprint Start Daily Scrum Abbildung 1: Ablauf einer Iteration am Beispiel von Scrum Sprint Review & Demo Sprint End Agile Softwareentwicklungsteams sind selbst organisiert und darauf fokussiert, dem Kunden das zu liefern, was ihm den grösstmöglichen Nutzen bringt. Durch die intensive Zusammenarbeit entsteht eine starke Bindung zwischen Kunde, Produkt und Entwicklungsteam. Der Ablauf einer Iteration (Sprint) wird am Beispiel von Scrum, wie in Abbildung 1 dargestellt, erklärt: Beim Planning Meeting (Sprint Planning) erläutert der Product Owner zu Beginn eines Sprints gegenüber dem Entwicklungsteam die Details der einzelnen Stories und legt die Akzeptanzkriterien pro Story fest. Alle Stories sind mit einer Priorität versehen und werden vom Team bezüglich ihres Aufwands geschätzt und in Tasks aufgeteilt. Daraus ergibt sich das Set der Stories, die das Team in der kommenden Iteration (Sprint) realisieren kann das Sprint Backlog. Das Team beginnt anschliessend mit der Umsetzung der Stories aus dem Sprint Backlog. Täglich findet dabei ein max. 15-minütiger Informationsaustausch (Daily Scrum) innerhalb des Teams statt. Eine User Story gilt als abgeschlossen, «Done», wenn sie gegen ihre Akzeptanzkriterien getestet und die Qualitätskriterien erfüllt wurden. Am Ende einer Iteration wird im Sprint Review und der Sprint-Demo dem Auftraggeber die implementierte Funktionalität gezeigt und zur Abnahme vorgelegt. Positive und negative Punkte sowie Verbesserungsvorschläge werden vom Team nach der Demo in einer Review- Sitzung (Sprint-Retrospective) diskutiert. 8 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 9
Team & Scrum sprache mit den Stakeholdern, um deren Bedürfnisse und Wünsche zu verstehen. Er ist für die Abnahme des Produkts als Ganzes, die Ergebnisse am Ende eines Sprints und den Produkterfolg des zu realisierenden Projekts verantwortlich. Abbildung 2: Rollen und Verantwortlichkeiten Stakeholder (Kunde) Product Owner Stakeholder sind Personen (z. B. Kunden, Anwender, Manager) oder Organisationen, die das Projekt finanzieren und daraus einen Nutzen ziehen wollen. Sie dürfen keinen Einfluss auf das agile Team ausüben und liefern dem Product Owner Feedback über Funktionsumfang und Benutzbarkeit des zu erstellenden Produkts. Der Product Owner ist für den Erfolg der Produktentwicklung verantwortlich. Ihm allein obliegt die Entscheidung über das Produkt, dessen Funktionalitäten und die Reihenfolge der Implementierung. So balanciert er Eigenschaften, Auslieferungszeitpunkte und Kosten. Als Produktverantwortlicher hält er regelmässig Rück- Der Scrum Master ist dafür verantwortlich, dass Scrum gelingt und von allen Teammitgliedern angewandt wird. Dazu arbeitet er mit dem Entwicklungsteam zusammen. Er sorgt dafür, dass die Teamleistung maximiert wird, indem er Probleme, die ein Sprintziel betreffen, auszuräumen versucht. Zusätzlich soll er dem Team helfen, seine Fähigkeiten als Ganzes zu erweitern. Das Team ist eine Gruppe von Experten und für die Lieferung der Produktfunktionalitäten in der vom Product Owner gewünschten Reihenfolge verantwortlich. Das Know-how der individuellen Experten geht mit der Zeit auf das gesamte Team über. Zudem trägt das Team die Verantwortung für die Einhaltung der vereinbarten Qualitätsstandards. Es organisiert sich selbst. Es lässt sich von niemandem, auch nicht vom Scrum Master, vorschreiben, wie es die User Stories umzusetzen hat. Alle Teammitglieder können vielfältige Aufgaben eines Sprints bearbeiten. Exklusive Rollen wie Tester, Programmierer oder Architekt werden im Team vermieden. Jedes Teammitglied bringt sein Expertenwissen ein. Wer die verschiedenen Aufgaben während eines Entwicklungszyklus (Sprint) ausführt, spielt keine Rolle mehr, am Ende müssen diese Aufgaben erledigt sein. «Agile Tester» im Entwicklungsteam Im Team verschwinden die Grenzen zwischen klassischen Testrollen wie Test Manager, Test Analyst oder Tester. Teilweise verschwimmen auch die Grenzen zwischen Entwickler und Tester. Durch Test- 10 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 11
aktivitäten soll die Entwicklung des Systems durch schnelles Feedback abgesichert werden. Die früher angestrebte Unabhängigkeit zwischen Entwickler und Tester wird zugunsten der engen Zusammenarbeit aufgegeben. Um jedoch Fehlerblindheit und zu starke Unbefangenheit des agilen Testers zu vermeiden, sollte die frühere Grenze nicht komplett aufgehoben werden. Beispiele individueller Fähigkeiten der Teammitglieder Softwareentwickler Der Softwareentwickler ist eine Person, die neue Funktionalität implementiert und produktiven Code schreibt inklusive Tests wie Unit-Tests oder Akzeptanztests. Das pure «Verwalten» von Testprozessen und -strategien durch klassische Test Manager passt jedoch nicht mehr so recht ins agile Umfeld. So übernimmt der Test Manager in agilen Projekten eher übergreifende Testaktivitäten, das heisst Testaufgaben, zu denen der agile (embedded) Tester im Scrum Team nicht in der Lage ist (z. B. End-to-End-Tests). Da der Begriff «Test Manager» mit klassischen Vorgehensmodellen in Verbindung gebracht wird, wird zur besseren Unterscheidung der agile Test Manager oft auch als «Test Master» bezeichnet (in Anlehnung an den Begriff «Scrum Master»). Testingenieur Der Testingenieur ist eine Person mit Spezialwissen bezüglich Qualitätssicherung und Softwaretest. Er unterstützt Entwickler, die auf Qualität gegenüber dem Kunden fokussiert sind. Testautomatisierungsexperte Der Testautomatisierungsexperte ist ein Experte für Tools und Methoden, die das Automatisieren von funktionalen und nicht funktionalen Tests betreffen. Typischerweise wird er für spezifische Testaufgaben und/oder permanent im Projektteam eingesetzt. Er stellt auch Anforderungen an Entwickler zur effizienteren Umsetzung der Testautomatisierung. (Nicht agiler) Test Manager vs. (agiler) Test Master Der «nicht agile» Test Manager ist in klassischen Vorgehensmodellen anzutreffen. Generell basiert seine Arbeit auf starren Teststufen, Quality Gates und definierten Testkonzepten. 12 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 13
4 AUTOMATISIERUNG Die Automatisierung verschiedenster Arbeitsabläufe des Entwicklungsprozesses im Allgemeinen und in der Testautomatisierung im Speziellen ist für agile Softwareentwicklungsprojekte von zentraler Bedeutung, da ein agiles Team am Ende eines Sprints funktionierende und qualitätsgeprüfte Software freigeben möchte. Die Qualität der Software kann nur durch permanentes, umfassendes Testen sichergestellt werden. Während des Sprints müssen permanent automatisierte Regressionstests lauffähig sein, um als «Sicherheitsnetz» bei Codeänderungen und Refactorings zu dienen. Weil die zu testende Funktionalität von Iteration zu Iteration zunimmt und damit auch die Anzahl der Regressionstests stetig ansteigt, ist es bereits nach wenigen Iterationen nicht mehr möglich, die gesamte bestehende Funktionalität gewissenhaft manuell zu überprüfen. Die Automatisierung von Testfällen löst dieses Problem und ermöglicht es, diese beliebig oft auszuführen. Dies gibt dem Tester Freiraum, die Anwendung zusätzlich mit explorativen Tests zu prüfen. Nicht nur Unit- und Integrationstests, sondern auch System- und Akzeptanztests müssen frühzeitig im Sprint (möglichst zeitgleich mit der Implementierung einer Story oder sogar davor im Sinne von «Test-First») entworfen und automatisiert werden. Wenn entwickelte Softwareteile noch nicht auf Systemebene getestet werden können (was häufig vorkommen kann), muss für den Systemtest eine eigene Story geschrieben werden, um verzögerungsfrei zu testen. 4.1 TEST-DRIVEN DEVELOPMENT (TDD), TEST-FIRST Die testgetriebene Entwicklung, engl. test-first development oder test-driven development (TDD), ist eine Methode, die häufig in der agilen Softwareentwicklung zum Einsatz kommt. TDD erfolgt in Verbindung mit Unit-Tests, Systemtests oder Akzeptanztests. Bei den Unit-Tests wird die Programmierung in Micro-Iterationen wiederholt. Jede Iteration besteht aus drei Hauptteilen: 1. Der Entwickler erstellt zuerst den Test (Greybox-Test) für das bestimmte erwünschte Verhalten einer Unit, für bereits bekannte Fehler oder eine neue Teilfunktionalität. Der ausgeführte Test wird zunächst vom bestehenden Programmcode noch nicht erfüllt, da es diesen noch gar nicht gibt. 14 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 15
2. Anschliessend schreibt/ändert der Entwickler den Code mit möglichst geringem Aufwand so lange, bis mit den nächsten Testdurchläufen alle Tests erfolgreich durchgelaufen sind. 3. Nun erfolgt das Refactoring, das heisst, der Code wird «aufgeräumt». Überflüssiger, duplizierter Code wird entfernt oder nach verbindlichen Code-Konventionen ausgerichtet. Im Gegensatz zu klassischen Vorgehensweisen wie Wasserfalloder V-Modell hat TDD den Vorteil, dass durch viele kleine automatisierte Tests die gewünschte Testabdeckung für das Refactoring in der gewünschten Qualität eher erreicht werden kann: Einfache Metriken: Tests werden bestanden oder nicht. Durch Refactoring in kleinen Schritten entstehen weniger Fehler (einfachere Fehlerlokalisierung). Unit-Tests beschreiben gleichzeitig, was das System leisten soll («eine ausführbare Spezifikation»). Durch die stärkere Modularisierung des Codes kann dieser leichter geändert oder gewartet werden. Trotzdem darf TDD nicht als Ersatz für andere Testarten betrachtet werden, weil durch TDD nicht alle Fehler aufgedeckt werden können (z. B. Fehler in den Anforderungen, in der Systemintegration oder Usability). TDD mit Systemtests hat nicht mehr das Ziel, dass schriftlich definierte Anforderungen erfüllt, sondern eher das spezifizierte Systemtests bestanden werden. In diesem Fall spricht man vom Acceptance-Test-Driven Development (ATDD). 4.2 ACCEPTANCE-TEST-DRIVEN DEVELOPMENT (ATDD) Die akzeptanztestgetriebene Entwicklung (ATDD) ähnelt zwar der testgetriebenen Entwicklung (TDD), ist jedoch eher ein Kommunikationswerkzeug zwischen Kunden/Anwender, Entwickler und Tester. ATDD soll sicherstellen, dass Anforderungen gut beschrieben sind. Die Tests der ATDD sollen für Nicht-Entwickler lesbar und verständlich sein. Oft werden die testgetriebenen Tests von den akzeptanzgetriebenen Tests abgeleitet. Fehler in den funktionalen/nicht funktionalen Anforderungen können durch TDD oft nicht aufgedeckt werden. Hier empfehlen sich ATDD wie Behaviour-Driven Development (BDD) oder Systemtests. 4.3 BEHAVIOUR-DRIVEN DEVELOPMENT (BDD) BDD (Behaviour-Driven Development) ergänzt TDD und ATDD durch Synthese und Verfeinerung, indem es eine strukturierte Sprache vorgibt, in welcher Businessprozesse beschrieben werden. So wird die Beschreibung eines Features durch ein oder mehrere Beispiele, die das Verhalten korrekt darstellen, verdeutlicht und über diese getestet. Konkret heisst dies, dass im Prinzip auch Stakeholder aus der Managementebene entsprechende Anforderungen definieren können, die dann in sogenannten Szenarios resultieren, also zu konkreten Testfällen werden. BDD verbessert die Lesbarkeit von Features und Szenarien, mit welcher sich auch technisch nicht versierte Stakeholder in das Projekt einbringen können. So lässt sich vermeiden, dass ein Stakeholder mit dem Produkt unzufrieden ist, da das Produkt genau dem entspricht, was er definiert hat. Im BDD gelten folgende Prinzipien: Wende für jede User Story das «Five Why s»-prinzip an, sodass ihr Zweck einen eindeutigen Bezug zu Geschäftsergebnissen erhält. «Denke von aussen nach innen» oder anders formuliert: 16 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 17
«Implementiere zunächst nur die Verhaltensweisen, die direkt etwas zu den Geschäftsergebnissen beitragen und minimiere Waste». Beschreibe Verhaltensweisen in Single Notations, die für Domain- Experten, Tester und Entwickler direkt zugänglich sind und verbessere die Kommunikation. Übernehme diese Techniken den ganzen Weg hinunter bis zu den tiefsten Ebenen der Abstraktion der Software, wobei ein besonderes Augenmerk auf der Verteilung des Verhaltens liegen sollte, damit die Evolution der Software günstig bleibt. BDD ist derzeit in aller Munde. Leider wird dabei zu häufig der Fokus nur auf Tools wie Cucumber oder JBehave gelegt. Die BDD-Prinzipien werden so häufig vergessen und missachtet. 4.4 DATA-DRIVEN TESTING (DDT)/ KEYWORD-DRIVEN TESTING (KDT) Das datengetriebene Testen ist eine relativ einfache Technik. Ein Test wird erstellt, parametrisiert und mit variierenden Daten ausgeführt. Positive und negative Testfälle werden mit unterschiedlichen Input-Daten ausgeführt, um die Testabdeckung eines einzelnen Tests zu erhöhen. Das Keyword-Driven Testing (auch Table-Driven Testing, Action- Word Testing) ist eine Technik der Testautomatisierung, die man auch für manuelle Tests verwenden kann. Die hohe Abstraktionsebene von solchen Schlüsselwort gesteuerten Tests verbessert die Wiederverwendbarkeit und die Wartbarkeit von Tests. KDT findet meist in zwei Etappen statt: Zu testende Aktionen/Operationen in der Anwendung oder Anforderungen analysieren Wiederkehrende Aktionen und Abläufe dann in Keywords kapseln Ein einfaches Keyword (eine Aktion auf einem Objekt) wäre z. B. «Eingabe von einem Benutzernamen in ein Textfeld». Ein komplexeres Keyword wäre z. B. «Einloggen». 4.5 MODEL-DRIVEN SOFTWARE DEVELOPMENT (MDSD) Das Model-Driven Software Development, kurz MDSD genannt, dient der Verbesserung der Softwarequalität, der Wiederverwendbarkeit sowie der Steigerung der Effizienz von Softwareentwicklungen. Die Definition formaler Modelle bildet die Basis des MDSD. Als formales Modell wird die vollständige Beschreibung eines abgegrenzten Teils der Software in grafischer oder textueller Notation bezeichnet. Dabei wird aus den formalen Modellen automatisiert lauffähige Software erzeugt. Im Fokus des MDSD liegt die Automatisierung des Softwareentwicklungsprozesses. Somit ist ein Modell, welches lediglich der Analyse, dem Entwurf oder der Dokumentation dient, kein Modell im Sinne des MDSD. Modelle im MDSD sind primär Entwicklungsartefakte für die Generierung des finalen Systems. Gemäss einer dreistufigen Modellhierarchie werden Systemanforderungen in formale Modelle abstrahiert, Modelle zu weiteren Metamodellen und schliesslich Metametamodelle automatisch zu ausführbarem Code transformiert. MDSD bietet die Vorteile, dass sich die Abstraktionsebene für das zu spezifizierende System detaillierter darstellt, eine durchgängige Kommunikation durch domänenspezifische Sprachen (DSL s) möglich ist und sich die Effizienz bei der Softwareerstellung durch die automatisierten Transformationen der erstellten Modelle bis zum generierten Code steigern lässt. Gleichzeitig verringern Modelle die Komplexität in Design und 18 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 19
Abbildung 3: Die agile Testpyramide Implementierung, indem Code-Duplizierungen reduziert werden. Zur Beschreibung der Modelle kommt meist UML (Unified Modeling Language) zum Einsatz. 4.6 AUTOMATISIERUNGSSTRATEGIE Unter Testautomatisierung wird im herkömmlichen Sinne meist die Verwendung eines Automatisierungswerkzeugs zur Ausführung von funktionalen Tests verstanden. In einem agilen Projekt erfolgen Automatisierungsaktivitäten über alle «Teststufen». tests not practical for automation provide acceptance and regression tests find gaps drive development Manual Testing Exploratory Testing System Acceptance Tests and Constraints Tests Executable Specifications Acceptance Test Driven Development Integration Tests (3rd-party components) Unit Test Test Driven Development automatically executed manually executed Die agile Testpyramide, angelehnt an die Automatisierungspyramide nach Mike Cohn, stellt auf einfache Weise dar, wie und wo sich die Tests und Automatisierungsaufgaben in einem agilen Projekt verteilen (Abbildung 3). Von zentraler Bedeutung ist, dass automatisierte Tests beliebig oft wiederholbar und möglichst oft ausgeführt werden. Eine Continuous-Integration-Umgebung, die automatisch einen kompletten Build erstellt und anschliessend Testfälle verschiedener Teststufen ausführt, bildet dafür eine unerlässliche Grundlage. 4.7 UNIT-/KOMPONENTENTEST Das Fundament einer durchgängigen Automatisierungslösung bilden Unit-Tests. Sie werden mit einfachen Werkzeugen immer Code nah erstellt und sind schnell in der Ausführung. Gleichzeitig ergibt sich durch agile Entwicklungsmethoden wie TDD testbarer Code und ein testbares Design. Wenn immer möglich sollen Tests auf dieser Stufe ausgeführt werden. 4.8 ACCEPTANCE-TEST/API-LAYER-TESTS In klassischen Projekten ist dies die am schwierigsten zu beschreibende Teststufe (Integrationstest). Die Software bzw. lauffähige Komponenten sollen hier als Ganzes über ihre Schnittstellen getestet werden zum Beispiel direkt unterhalb des GUI. Die Testfälle sind hier auf Basis der Akzeptanzkriterien der User Stories bereits mit konkreten Werten für Geschäftsvorfälle belegt und in Form von Aktionen und erwarteter Ausgabe aufgelistet und ausführbar. Mit geeigneten Entwicklungswerkzeugen können diese in einer formalen Form spezifiziert, festgehalten und schlussendlich automatisch ausgeführt werden (Executable Specifications). 4.9 SYSTEMTEST/GUI-TEST Innerhalb einer Automatisierungslösung sind GUI-Tests die Tests, bei denen erfahrungsgemäss ein hoher Aufwand bei hoher Wartungs- 20 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 21
intensität erwartet werden kann, da viele Objekte, Aktionen und Ereignisse über die grafische Schnittstelle (GUI) berücksichtigt werden müssen und die Ausführung im Vergleich zu anderen Teststufen sehr lange dauert. Die Anzahl an GUI-Tests sollte daher möglichst klein gehalten werden. Jedoch kann nicht gänzlich auf sie verzichtet werden, da viele GUI-Elemente oft das gesamte System (Systemtest) betreffen. Nicht funktionale Anforderungen oder Vorgaben, die nicht als Business Requirements bezeichnet werden können (Constrains), lassen sich meist erst mit dem Gesamtsystem prüfen. abgedeckt werden. Ziel ist es, am Ende möglichst das gesamte funktionale Spektrum der Software durch Tests abzudecken. 4.11 BEISPIELE Weiterentwicklung einer bestehenden Lösung: Bei der Umstellung eines laufenden Softwareentwicklungsprojekts auf agile Projektmethoden trifft man meist folgende Situation an: Für den bestehenden Code existieren keine oder kaum Unit-Tests, die Architektur lässt keine API-Tests zu. 4.10 EXPLORATIVES TESTEN Beim explorativen Testen (Exploratory Testing) handelt es sich um eine informelle Testtechnik, bei der der Tester das Testdesign während einer Session aktiv kontrolliert, während er diese Tests simultan ausführt. Der Tester verwendet die bei der Testausführung neugewonnenen Informationen, um neue und bessere Tests zu designen. Erfahrungsgemäss kommt exploratives Testen im Scrum Team besonders gut an, da es über die üblichen vorgegebenen Testpläne und Done- Kriterien hinausgeht. Zwangsläufig muss hier zu Beginn ein Automatisierungsansatz gewählt werden, der zunächst nur GUI-Testautomatisierung beinhaltet. Die wichtigste Funktionalität soll über ein kleines Set von GUI-Testfällen geprüft werden. Im Rahmen der Weiterentwicklung sollen bestehende Codeteile so umgeschrieben werden, dass der Code mit Unit-Tests versehen wird und die Architektur auch die Erstellung von automatisierten Acceptance-Testfällen unterhalb des GUIs zulässt (vorausgesetzt die GUI bleibt weitestgehend unverändert). Dadurch wird mit der Zeit eine Verteilung der Testfälle über Teststufen entstehen, die in der Anzahl der Gewichtung der Automatisierungspyramide entsprechen wird. Exploratives Testen ist simultanes Lernen, Testdesign und Testausführung und ist charakterisiert durch: Abbildung 4: Umsetzung der Automatisierungsstrategie Time-Boxing: Test-Sessions mit fixer Dauer Charter: Schriftliche Mission für den Tester Simultanes Testdesign und Testausführung Einsatz von Heuristiken Keine Automatisierung GUI-Tests für Hauptfunktionen Auf- und Ausbau der Testautomatisierung Unit-, API- und GUI-Tests Das Vorgehen des explorativen Testens ist eher risikoorientiert, statt spezifikationsorientiert, das heisst, die Suche fokussiert sich eher auf mögliche Fehlersituationen, die noch nicht durch bisherige Testfälle 22 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 23
5 TESTPLANUNG Auch im leichtgewichtigen agilen Umfeld macht es Sinn, sich Teststrategie und Testplan zurechtzulegen. Es reicht nicht, nur zu definieren, dass alle Akzeptanzkriterien erfolgreich getestet sein müssen. Wann sind diese abschliessend getestet und nach welchen Gesichtspunkten soll dies geschehen? Testing Programmierung Kundenteam Sprint 1 Feedback Sprint 2 Feedback Change Requests, Bugfixes, Wünsche Sprint 3 Feedback Sprint 4 Feedback Testautomatisierung, Explorativer Test Sprint 5 Feedback Sprint 6 Feedback Sprint 7 Feedback Sprint-Demos, Akzeptanztest Unit-Test, automatisiert Sprint 8 Feedback Sprint 9 Feedback Sprint 10 Feedback Release Testaktivitäten Testfälle total Testdesign, manueller Regressionstest automatisierte Testfälle Feature Complete Abbildung 6: Testmanagement im agilen Umfeld Abbildung 6 verdeutlicht die Verteilung der Testaufwände über mehrere Iterationen (Sprints) zwischen Kunde, Programmierer und Tester. Durch Testautomatisierung wächst zwar die Gesamtanzahl der Testfälle, gleichzeitig sinkt jedoch der Aufwand für Testdesign und die Durchführung manueller (Regressions-)Tests. Während sich in den ersten Sprints die Testaktivitäten lediglich auf die Akzeptanzkriterien beschränken, bleibt mit zunehmender Testautomatisierung mehr Zeit für die Durchführung explorativer Tests, was bei Zunahme des Umfangs und der Komplexität der Software als sehr sinnvoll betrachtet werden kann. Agile Tester sollten beachten, dass User Stories des Product Owners (auf Kundenwunsch) umpriorisiert werden können. Dies muss bei den Testaktivitäten berücksichtigt werden. Teststrategie und Testplan sollten so unkompliziert und einfach wie möglich sein die Planung steht im Vordergrund, nicht der Plan. 24 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 25
Anpassungsfähigkeit Installierbarkeit Austauschbarkeit Modularität Wiederverwendbarkeit Analysierbarkeit Modifizierbarkeit Prüfbarkeit Vertraulichkeit Integrität Nachweisbarkeit Verantwortlichkeit Authentizität Ausgereiftheit Verfügbarkeit Fehlertoleranz Wiederherstellbarkeit Übertragbarkeit (Portability) Wartbarkeit (Maintainability) Sicherheit (Security) Zuverlässigkeit (Reliability) ISO 25010 Funktionalität (functional suitability) Effizienz (Performance efficiency) Kompatibilität (Compatibility) Benutzbarkeit (Usability) Vollständigkeit Korrektheit Angemessenheit Antwortzeitverhalten Ressourcenverbrauch Kapazität Koexistenz Interoperabilität Angemessenheit Erkennbarkeit Erlernbarkeit Bedienbarkeit Fehlertoleranz ggü. Anwenderfehlern Ästhetik der Benutzeroberfläche Barrierefreiheit Abbildung 8: Die agilen Test-Quadranten nach Crispin/Gregory 5.2 TESTSTRATEGIE Auch im agilen Testen sollten Überlegungen zu einzelnen Testmethoden, Werkzeugen und Teststufen in einer Teststrategie festgehalten werden. Hierbei handelt sich um eine Dokumentation, die sehr wenig geändert werden muss und relativ abstrakt den Testprozess in einem Projekt beschreibt. Als Hilfsmittel zur Ableitung einer Teststrategie sollten die durch die Qualitätsziele definierten Qualitätsaspekte berücksichtigt werden. Hierzu kann die Darstellung der agilen Testing-Quadranten herangezogen werden. Abbildung 7: Qualitätsziele nach ISO 25010 5.1 QUALITÄTSZIELE Um Testaktivitäten gezielt einzusetzen und um damit auch die Entwicklung entsprechend treiben zu können, ist es wichtig, dass für die neu zu erstellende Anwendung bzw. das zu realisierende Projekt Qualitätsziele definiert werden, die speziell beachtet werden sollen. Ist für den Kunden beispielsweise Performance (Time Behaviour) von essenzieller Bedeutung, dann sollten sich auch die Testaktivitäten dahingehend fokussieren. Automatisiert und manuell Team unterstützen Automatisiert Funktionale Tests Beispiele Story Tests Simulationen Prototypen Unit Tests Komponenten Tests Kundenorientiert Q2Q3 Q1Q4 Technologieorientiert Explorativer Test Szenarien Usability Testing UAT (User Akzeptanz Test) Alpha/Beta Test Performance & Load Test Security Test «-ility» Tests Manuell Produkt prüfen Werkzeuge Zur Auswahl entsprechender Qualitätsziele eignet sich beispiels- weise die Qualitätsnorm ISO 25010 (siehe Abbildung 7). Je nach Projekt soll eine Teststrategie folgende Punkte enthalten: zum Beispiel Automatisierungsansatz, Reporting, Testmethodik, Test-Tools, Fehlermanagement etc. Dabei sollte der Testquadrant auf jede User Story angewendet werden, um die optimalen Testarten und Vorgehensweisen zu bestimmen. Welche Testarten 26 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 27
letztendlich dem Team und Kunden helfen, den grössten Nutzen zu erzielen, hängt von der gewählten Strategie bzw. den selbst gewählten Vorgaben aller vier Quadranten ab, um Stories abzuschliessen («Definition of Done»). 5.3 TESTPLAN Der Begriff «Testplan» wird oft mit dem Begriff «Testkonzept» gleichgesetzt. Jedoch stellt das Testkonzept eher den statischen Teil und der Testplan den über die Projektlaufzeit eher dynamischen Teil dar. Für ein Scrum Team kann die Existenz eines dynamischen High-Level-Testplans wertvoll sein, damit team-/sprintübergreifende Testaktivitäten stets berücksichtigt werden. Generell wird der Testplan von einem Test Master («agilen» Test Manager) ausserhalb des Scrum Teams erstellt. Abbildung 9: Beispiel eines Teststatusreports 5.4 TESTSTATUSREPORT Für eine Iteration kann es genügen, Funktionalität und zu testende Ausprägungen in Matrixform gegeneinander aufzulisten. Durch farbliche Markierungen gibt der Teststatusreport pro Sprint- Backlog-Item einen kurzen Überblick, welche Funktionalitäten bereits getestet wurden bzw. welche noch zu testen sind, wo es kritische Probleme gibt etc. Zum Ende der Iteration sollten zu jeder User Story die erforderliche Akzeptanzkriterien existieren und alle Testfälle zu diesem Zeitpunkt erfolgreich ausgeführt worden sein (100% Test Success und 100% Test Process). Nach Möglichkeit sollten zum Sprint-Ende auch alle gefundenen Bugs pro Item beseitigt worden sein (Zero-Bug- Strategie). Der regelmässige Aushang des Teststatusreports im Team-Büro ist enorm wichtig. So erhalten alle Teammitglieder und Stakeholder während des Sprints eine höhere und plakative Transparenz über den aktuellen Teststatus. 28 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 29
6 PROFIL DES AGILEN TESTERS In einem idealen agilen Softwareprojekt gibt es keine separate Testabteilung mehr. Ebenso entfallen die klassischen Testrollen wie Test Manager, Test Analyst oder Tester. Die dedizierte exklusive Rolle des Programmierers, der einfach Code nach Belieben schreibt und an eine Testabteilung weiterreicht, hat ausgedient. Aber was unterscheidet nun den agilen Tester vom klassischen Tester? Welche Fähigkeiten und Kenntnisse braucht ein agiler Tester? Agile Vorgehensweisen stellen neue Anforderungen an Tester, die in agilen Entwicklungsteams als Experten mit Testing-Know-how tätig sind: Agile Tester unterstützen eine hohe Kundenzufriedenheit durch eine enge Zusammenarbeit mit dem Product Owner (Kunden), insbesondere in Bezug auf Akzeptanzkriterien. Sie können somit die qualitativen Auswirkungen von Änderungen besser nachvollziehen; sorgen für eine hohe Softwarequalität, durch Unterstützung des Entwicklerteams in Bezug auf gemeinsames Pair-Testing, konsequente Fehlerprävention und frühzeitige Fehlerfindung; unterstützen eine hohe Entwicklungsgeschwindigkeit, durch Reduktion von Waste (unnötige Testdokumentation, unnötige Fehlerkorrekturarbeiten); sind Teil eines selbst organisierten Teams und unterstützen dieses durch kontinuierliches Feedback und Face-to-face Kommunikation; sind Coaches, die dem Team helfen, durch geeignete Testmethoden sinnvoll, nachhaltig und gut zu testen. Je besser die Tests, umso eher steigt die Softwarequalität; reagieren sehr schnell auf Änderungen, die durch die kurzen Iterationen ermöglicht werden; besitzen eine hohe Teammotivation; berücksichtigen, je nach Umfeld, darüber hinaus aber auch die Werte aus klassischen Vorgehensmodellen (z. B. gute Planbarkeit, Rückverfolgbarkeit, Nachweisbarkeit der Testaktivitäten, systematisches Testen mit hoher Testabdeckung). 30 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 31
7 TESTAKTIVITÄTEN IN EINER ITERATION 7.1 RELEASE-PLANUNG UND PRE-PLANNING Obwohl nach jedem Sprint fertige, das heisst «shippable» Software zur Verfügung steht, empfehlen sich optional, je nach Projektgrösse und -komplexität, mittelfristige Veröffentlichungen der Software nach drei bis vier Monaten, also erst nach mehreren Sprints, weil beispielsweise: noch User Stories fehlen, die erst im Zusammenspiel mit anderen bereits umgesetzten User Stories den wahren Business Value für den Kunden generieren; der Kunde basierend auf der Produktvision nicht regelmässig, sondern selbst den geeigneten Zeitpunkt für die Veröffentlichung der Software bestimmen möchte; sich der Aufwand durch permanente Neukonfigurationen des Systems erhöht und durch Fehlkonfigurationen die Stabilität laufender Geschäftsprozesse erheblich gefährdet wird. Aufgrund dessen nimmt der agile Tester an der alle drei Monate stattfindenden Release-Planungssitzung teil, in der die höchstpriorisierten Entwicklungsvorhaben durch alle beteiligten Teams konkretisiert, auf Abhängigkeiten zwischen den Teams geprüft und auf die Sprintziele der einzelnen Teams verteilt werden. Der Product Owner erstellt hieraus den resultierenden Release- Plan, der eine Übersicht über den Zeit- und Kostenrahmen und Termine für Zwischenergebnisse und Fertigstellung beinhaltet. Grob enthält er die Reihenfolge der Umsetzung der Anforderungen und die erwartete Anzahl Sprints. Die Anzahl Sprints ist dabei abhängig von der Entwicklungsgeschwindigkeit (Velocity) des Teams. Diese wird in Story Points gemessen. Anhand der Velocity und der Aufwandsschätzungen des Teams ergibt sich dann, wie viele User Stories das Team innerhalb eines Sprints umsetzen kann. Der Release-Plan wird vom Product Owner in jedem Sprint aktualisiert. 32 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 33
In der Pre-Planning-Sitzung diskutiert der Product Owner mit dem Team/agilen Tester vorab die User Stories, die er im nächsten Planning Meeting, zu Beginn des nächsten Sprints, präsentieren möchte. Dies versetzt den agilen Tester vorab bereits in die Lage, neue Testszenarien zu erarbeiten und Akzeptanzkriterien zu neuen User Stories mit dem Product Owner gemeinsam abzustimmen. Er kann diese dann im nächsten Planning Meeting einbringen. 7.2 ITERATIONSPLANUNG Die Iterations-/Sprintplanung, also die Planung der nächsten zwei bis vier Wochen, findet im Planning Meeting statt. Ziel ist es, möglichst alle Unklarheiten im Verständnis der Stories zu beseitigen, die Stories in Tasks aufzuteilen und den Arbeitsaufwand für die Tasks oder die Stories zu schätzen. Aus der Sicht des Testers bedeutet dies: Einbringen der Sichtweise und Überlegungen des Testes bei der Diskussion um Stories und deren Aufteilung in Tasks. Klärende Details bereits in Form von Testfällen festhalten. «Design for Test» auf Integrations- und funktionaler GUI-Testebene prüfen. Abschätzen des Testaufwands als Teil des Entwicklungsaufwands einer Story. Je nach Komplexität kann dieser erheblich grösser sein als der Programmieraufwand. Ergebnis: Nach Abschluss des Planning Meetings hat das Team eine klare Vorstellung, welche Testfälle nötig sind, oder es kann diese bereits im Planning Meeting vollständig definieren. 7.3 UMSETZUNG Nach dem Planning Meeting beginnen die operativen Programmier- und Testaktivitäten. Programmierseitig entsteht neue Funktionalität zusammen mit Unit-Tests. Damit die Tester nicht bis zum Ende der Iteration warten müssen, bis sie mit den explorativen, funktionalen und nicht funktionalen Acceptance- Tests beginnen können, sollten erste Stories möglichst schnell umgesetzt und testbar sein. Tester beginnen ihrerseits schnellstmöglich mit der Realisierung konkreter Testfälle. Sind die Testfälle sehr früh vorhanden, helfen sie den Programmierern bei der Umsetzung der Story, sodass diese bereits alle Variationen von Eingaben für die bearbeitete Softwarekomponente kennen. Während der Entwicklung können die Testfälle zur Prüfung der geänderten oder neuen Funktionalität herangezogen werden. Tauchen während der Umsetzung einer Story Fragen auf, die vom Product Owner beantwortet werden müssen, werden diese nach dem Prinzip «Power of Three» geklärt, das heisst Tester, Product Owner und Programmierer lösen gemeinsam vor Ort die Problematik einer Story. Sind Stories programmierseitig abgeschlossen, führen Programmierer einen Walkthrough bzw. eine Demonstration gegenüber dem Tester durch («Show me»), bevor Code eingecheckt und explorativ und funktional getestet wird oder automatisierte GUI-Tests entstehen. Grundsätzlich arbeiten Tester und Programmierer zusammen, um Umsetzung und Test gemeinsam zu optimieren. 7.4 «THE END GAME» In agilen Kreisen wird die Zeit kurz vor Produktionseinführung oft «End Game» genannt. «The End Game» beschreibt die Zeit vor dem «Live-Betrieb», in der die letzten Testaktivitäten wie 34 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 35
User-Akzeptanz-Test (UAT), finale Abnahmetests, Regressionstests oder nicht funktionale Test wie Load- und Performancetests durchzuführen respektive vor dem endgültigen Rollout abzuschliessen sind. Dokumentationen und Handbücher sind zu vervollständigen. In dieser letzten Phase vor dem Rollout sollte darauf verzichtet werden, noch unkritische Fehler zu beheben oder neue Stories zu beginnen, weil es dadurch unter Umständen zu erneuten Fehlern kurz vor der Produktionseinführung kommen kann. Planen Sie ausreichend zeitliche Reserven für das End Game ein und nutzen Sie diese Rollout-Vorbereitungszeit für Testaktivitäten wie abschliessende integrative und explorative Tests, Installationstests, Datenbankupdates, Datenkonvertierungen oder Kompatibilitätstests (bei Datenmigrationen). Führen Sie einige End-to-End-Szenarien durch und fokussieren Sie Ihren Blick auf die Softwarequalität des Gesamtsystems. Beachten Sie zudem, dass im Rahmen des Continuous Deployments, das heisst mit Auslieferung des ersten Releases an den Kunden, Themen wie Setup, Installer, Berechtigungen, Zertifikate, Updates, Patches etc. geklärt sein müssen. 7.5 USER-AKZEPTANZ-TEST (UAT) Beim User-Akzeptanz-Test (UAT) wird neue Funktionalität von einem grösseren Benutzer-/Kundenkreis getestet. Funktionale Tests von Benutzerszenarien werden vom Kunden manuell mit der vollständig integrierten Software unter möglichst realen Bedingungen und Daten ausgeführt. Grundsätzlich gilt, den UAT so früh wie möglich durchzuführen, um anfallende Änderungswünsche rasch in die Entwicklung einfliessen lassen zu können. Und dies ist ein zentraler Punkt: Ein Feature darf nur dann «Done» sein, wenn der UAT erfolgreich war, das wird auch laufend in den Sprints angewendet. Der UAT beim End Game ist schliesslich die letzte Bestätigung der vorangegangenen UATs. 7.6 FEEDBACK Eine der zentralen Aufgaben der gesamten Test- und Qualitätsaktivitäten ist das Generieren von Feedback: Agile Tester liefern permanent Feedback zu Abweichungen in der Softwarequalität. Continuous Integration, Unit-Tests und Acceptance-Tests liefern permanent Feedback über den Zustand der Anwendung nach Codeänderungen. Der Product Owner (Scrum) liefert Feedback zur realisierten Funktionalität bei der Abnahme der Sprintergebnisse und lässt dieses direkt ins Product Backlog in Form neuer User Stories einfliessen. Senior User liefern dem Product Owner laufend Feedback zur Benutzbarkeit der Anwendung, bei Bedarf auch direkt dem Entwicklungsteam. Stakeholder liefern ebenfalls dem Product Owner Feedback zum Stand von Software und Projekt. Sie sind es auch, die formale Releases freigeben und gutheissen. User Groups liefern beim User-Akzeptanz-Test bzw. durch die Nutzung des neuen Systems Feedback. Ihr Feedback fliesst über Qualitätsziele wieder ins Product Backlog ein. 36 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 37
8 ERFOLGSFAKTOREN Nachfolgend sind die aus Sicht der bbv Software Services AG wichtigsten Faktoren für ein erfolgreiches Integrieren von Testaktivitäten in agile Softwareprojekte aufgelistet. 8.1 DAS GANZE TEAM IST VERANTWORTLICH Seien Sie sich als agile Tester bewusst: Das Team als Ganzes ist für die Qualität der Software und die damit verbundenen Test- und Automatisierungsaufgaben verantwortlich. Die klassische Trennung in Entwicklung und Test verschwindet. Sie bringen Ihr Fachwissen zu Testaktivitäten in das Team ein und legen Ihr ursprüngliches Label der «Qualitätspolizei» ab. Sie haben Ihr Agile-Testing Mindset aufgebaut und setzen nun alles daran, dass das Team das Produkt in bestmöglichster Qualität liefert. Entwickler unterstützen Sie dabei und integrieren Sie ins Team. Sie wiederum helfen dem Team bei den Testaktivitäten. 8.2 SAMMELN UND LIEFERN SIE FEEDBACK Kommunikation und Feedback sind für agile Teams von grosser Bedeutung. Jedes Teammitglied trägt mit seinem Fachwissen zur Umsetzung von Stories und zur Klärung von Kundenanforderungen bei Sie als agiler Tester eignen sich besonders gut für Letzteres. Sie bringen sich durch Ihre besondere Sichtweise und Ihre Skills bei der Beurteilung von Stories und der Lösung von Problemen ins Team ein. 8.3 AUTOMATISIEREN SIE REGRESSIONSTESTS Durch die Automatisierung der Testfälle schaffen Sie ein Sicherheitsnetz, womit Sie rasch das Verhalten der Software nach durchgeführten Änderungen ermitteln und bewerten können. Sie minimieren somit das Risiko, Fehler aufgrund der Änderungen zu erhalten, und schaffen sich gleichzeitig mehr Freiraum, Ihre Testaktivitäten zum Beispiel durch gezielte explorative Tests zu erweitern. Denken Sie daran: Automatisierte Regressionstests sind eine Teamaufgabe. 38 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 39
8.4 BEHALTEN SIE DEN ÜBERBLICK Als Tester haben Sie den Überblick über die entwickelte Software als Ganzes («Big Picture»). Programmierer sind meist auf die Story fixiert, die sie grade bearbeiten und tendieren eher dazu, ihre Arbeit als beendet zu betrachten, wenn der Code funktioniert, während Sie als Tester eine umgesetzte Story auch mit Sonderfällen zu berücksichtigen wissen, um unentdeckte, kritische Fehler zu finden. 8.5 FÜHREN SIE BEI BEDARF RUHESPRINTS EIN Je nach Situation und Anzahl offener Bugs (Priority/Severity) bietet es sich oft an, einen sogenannten «Ruhesprint» (Stabi-Sprint) einzuführen. In diesem Sprint werden dann nur Bugs behoben und KEINE neuen Features implementiert. Generell gibt es Ruhesprints nur in halb agilen oder nicht agilen Projekten 8.6 NUTZEN SIE AGILE KERNPRAKTIKEN Als agiler Tester sollten Sie agile Kernpraktiken nutzen: Continuous Integration (Source-Code sollte mindestens einmal täglich eingecheckt sein, damit etwas testbar ist). Jede Integration durch automatisierte Builds absichern. Agile Tester brauchen ihre eigene, kontrollierbare Testumgebung. Plädieren Sie für eine «Refactoring Iteration» bei zu vielen Fehlern aufgrund technischer Schwierigkeiten. Setzen Sie auf «test-code-test-code-test»-iterationen und testen Sie inkrementell, das heisst, testen Sie zunächst jede kleine Teilfunktion für sich und testen Sie erst danach diese Teilfunktionen sukzessive zusammengefügt. 8.7 BINDEN SIE DEN KUNDEN MIT EIN Als agiler Tester eignen Sie sich hervorragend, um als Bindeglied zwischen dem Entwicklungsteam und dem Kunden zu fungieren. Sie denken aus Kundensicht, sprechen die Domänensprache des Business, gleichzeitig beherrschen Sie jedoch auch die technische Sprache der Entwickler. Durch Ihre spezielle Sicht und Ihr Fachwissen helfen Sie dem Kunden, seine Wünsche zu formulieren. Entsprechend wird der Kunde in die Umsetzung des Softwareprojekts eingebunden. Gleichzeitig können Sie als agiler Tester dem Kunden konkrete Benutzerszenarien und Beispiele veranschaulichen, sodass diese anschliessend in ausführbare Tests übersetzt werden können. 8.8 SEIEN SIE ALS AGILER TESTER FRÜHZEITIG DABEI Tester können viel mehr als nur Fehler finden. Sie haben gute Ideen, können Abläufe optimieren, auf Designfehler hinweisen und gute Empfehlungen zur Optimierung der GUI oder zur Usability geben. Dies ist jedoch nur dann möglich, wenn Sie auch frühzeitig ins Team eingebunden werden und somit rechtzeitig noch Probleme vor dem Rollout erkennen können. Insbesondere agile Tester können bei frühzeitigem Einsatz ihre Regressionstests optimieren bzw. vereinfachen. Somit sind Sie, der agile Tester, ein wertvoller Erfolgsfaktor für den Kunden. Sie sorgen somit für eine hohe Softwarequalität in agilen Projekten, die zu einer hohen Kundenzufriedenheit führt. 40 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 41
9 ANHANG 9.1 AUTOR Frank Kayser ist Senior Test Manager und Experte für agiles Testen. Er besitzt langjährige praktische Erfahrung in agilen Projekten. Er ist diplomierter Informatiker (FH), Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), ISTQB Certified Software Tester Advanced Level, IREB Certified Professional for Requirements Engineering und Quality Assurance Management Professional (QAMP). Als Fachleiter des bbv Kompetenzcenters Software-Testing stellt er die Weiterentwicklung von Kompetenzen und Dienstleistungen der bbv Software Services AG durch Innovationsprojekte sicher. 9.2 REFERENZEN [1] Lisa Crispin, Janet Gregory, Agile Testing, Addison-Wesley, 2009 [2] Mike Cohn, Succeeding with Agile, Addison-Wesley, 2009 42 COPYRIGHT 2016, BBV SOFTWARE SERVICES AG COPYRIGHT 2016, BBV SOFTWARE SERVICES AG 43
bbv Software Services AG ist ein Schweizer Software- und Beratungsunternehmen, das Kunden bei der Realisierung ihrer Visionen und Projekte unterstützt. Wir entwickeln individuelle Softwarelösungen und begleiten Kunden mit fundierter Beratung, erstklassigem Software Engineering und langjähriger Branchenerfahrung auf dem Weg zur erfolgreichen Lösung. Beratung Engineering ERFOLG Lösungen Ausbildung Unsere Booklets und vieles mehr finden Sie unter www.bbv.ch/publikationen MAKING VISIONS WORK. www.bbv.ch info@bbv.ch