Software in agilen Projekten by bbv Software Services

Booklet

SOFTWAREQUALITÄT IN AGILEN PROJEKTEn

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

Profitieren Sie von unserer Erfahrung!

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.

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

Inhalt 1 Einleitung

Agile Softwareentwicklung

Rollen und Verantwortlichkeiten

Begrifflichkeiten rund um den Test

4.1

Automatisierte Regression

4.2

Test-Driven Development (TDD), Test-First

4.3

Acceptance-Test-Driven Development (ATDD)

4.4

Behaviour-Driven Development (BDD)

4.5

Data-Driven Testing (DDT) / Keyword-Driven Testing (KDT) 18

4.6

Model-Driven Software Development (MDSD)

4.7 Automatisierungsstrategie

4.8 Unit-/Komponententest

4.9 Acceptance-Test/Api-Layer-Tests

4.10 Systemtest/Gui-Test

4.11

Exploratives Testen

4.12

Automatisierung einer bestehenden Lösung

4.13

Bimodale IT

4.14 DevOps

4.15

Shift Left

4.16

Cynefin Framework

5 Testplanung

5.1 Qualitätsziele

5.2 Teststrategie

5.3 Testplan

5.4 Teststatusreport

Profil des agilen Testers

Testaktivitäten in einer Iteration

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

7.1

Release-Planung und Pre-Planning

7.2 Iterationsplanung

7.3 Umsetzung

7.4

The End Game

7.5

User-Akzeptanz-Test (UAT)

7.6 Feedback

8 Erfolgsfaktoren

8.1

Das ganze Team ist verantwortlich

8.2

Sammeln und liefern Sie Feedback

8.3

Automatisieren Sie Regressionstests

8.4

Behalten Sie den Überblick

8.5

Führen Sie bei Bedarf Ruhesprints ein

8.6

Nutzen Sie agile Kernpraktiken

8.7

Binden Sie den Kunden mit ein

8.8

Seien Sie als agiler Tester frühzeitig dabei

9 Anhang

9.1 Referenzen

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

1 Einleitung Software ist in unserer modernen Gesellschaft nicht mehr wegzudenken. Verkürztes Time-to-Market bei hoher Softwarequalität sind inzwischen 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. Copyright © 2017, bbv Software Services AG

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

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. 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 sollen die wesentlichen Highlights und Erfolgsfaktoren des Testens in agilen Projekten am Beispiel des Vorgehensmodells Scrum zusammengefasst werden.

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

2 Agile Softwareentwicklung 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? 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 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.

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

Sprint Retrospective Sprint Planning

Sprint Review & Demo

Daily Scrum

Sprint Start

Sprint End

Abbildung 1: Ablauf einer Iteration am Beispiel von Scrum

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 ReviewSitzung (Sprint-Retrospektive) diskutiert. 8

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

3 Rollen und Verantwortlichkeiten 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.

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

Team & Scrum

Stakeholder (Kunde) Product Owner

Abbildung 2: Rollen und Verantwortlichkeiten

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ück10

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

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. 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 TestCopyright © 2017, bbv Software Services AG

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

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. • 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

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

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»).

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

4 BEGRIFFLICHKEITEN RUND UM DEN TEST

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

4.1 AUTOMATISIERTE REGRESSION 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 Unitund 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.2 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 Mikro-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 ausgeCopyright © 2017, bbv Software Services AG

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

führte Test wird zunächst vom bestehenden Programmcode noch nicht erfüllt, da es diesen noch gar nicht gibt. 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 dass spezifizierte Systemtests bestanden werden. In diesem Fall spricht man vom Acceptance-Test-Driven Development (ATDD). 16

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

4.3 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.4 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 du einen eindeutigen Bezug zu Geschäftsergebnissen erhältst. • «Denke von aussen nach innen» oder anders formuliert: Copyright © 2017, bbv Software Services AG

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

«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 DomainExperten, Tester und Entwickler direkt zugänglich sind, und verbessere die Kommunikation. • Übernimm 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.5 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, ActionWord 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 18

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

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.6 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 (DSLs) 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 Copyright © 2017, bbv Software Services AG

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

Implementierung, indem Code-Duplizierungen reduziert werden. Zur Beschreibung der Modelle kommt meist UML (Unified Modeling Language) zum Einsatz. 4.7 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

manually executed

Manual Testing

Exploratory Testing

Executable Specifications – Acceptance Test Driven Development

Integration Tests (3rd-party components) Unit Test – Test Driven Development

automatically executed

System Acceptance Tests and Constraints Tests

drive development

provide acceptance and regression tests

find gaps

Abbildung 3: Die agile Testpyramide

tests not practical for automation

Automatisierungsaktivitäten über alle «Teststufen».

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

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.8 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.9 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 der 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.10 SYSTEMTEST/GUI-TEST Innerhalb einer Automatisierungslösung sind GUI-Tests die Tests, bei denen erfahrungsgemäss ein hoher Aufwand bei hoher WartungsCopyright © 2017, bbv Software Services AG

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

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 kleingehalten 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. 4.11 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 DoneKriterien hinausgeht. Exploratives Testen ist simultanes Lernen, Testdesign und Testausführung und ist charakterisiert durch: • Time-Boxing: Test-Sessions mit fixer Dauer • Charter: schriftliche Mission für den Tester • Simultanes Testdesign und Testausführung • Einsatz von Heuristiken 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

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

abgedeckt werden. Ziel ist es, am Ende möglichst das gesamte funktionale Spektrum der Software durch Tests abzudecken. 4.12 AUTOMATISIERUNG EINER BESTEHENDEN LÖSUNG 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. 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 der GUI 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.

Abbildung 4: Umsetzung der Automatisierungsstrategie Keine Automatisierung

GUI-Tests für Hauptfunktionen

Auf- und Ausbau der Testautomatisierung

Unit-, API- und GUI-Tests

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

4.13 BIMODALE IT Der Begriff «Bimodale IT» umfasst im Wesentlichen den Spannungsbogen, in dem sich die Unternehmen heute bez. ihrer bestehenden Produkte und Dienstleistungen sowie der deutlich gestiegenen Anforderungen des Marktumfelds im Zusammenhang mit Innovation, Digitalisierung und «Time-to-Market» von neuen Produktideen bewegen. Aus IT-Sicht gibt es auf der einen Seite die bestehenden, gut bekannten, bewährten, ggf. aber auch schwerfälligen Systeme und Technologien mit ihren obligatorischen Entwicklungs- und Wartungszyklen. Auf der anderen Seite werden neue Ideen auf Basis von aktuellen oder neuen Technologien entwickelt, die dann möglichst schnell intern oder extern verfügbar gemacht werden sollen. Beim Vorgehen unterscheidet man zwischen den zwei unterschiedlichen, aber kohärenten Ansätzen Predictability (Vorhersehbarkeit, Berechenbarkeit, Planbarkeit) und Exploration (Erforschung, Erkundung). Mode 1 – Predictability ist optimal für Bereiche, die bereits gut verstanden, bekannt und planbar sind. Der Ansatz konzentriert sich auf die Nutzung von Bekanntem, um bspw. die «bestehende» Umgebung fit für die digitale Zukunft zu machen. Für IT-Projekte bieten sich (aufgrund der Abhängigkeiten) eher die klassischen Vorgehensmodelle an, wie bspw. V-Modell, lange Releasezyklen etc. Diese Projekte erfordern Mitarbeiter mit Erfahrung und entsprechendem Know-how. Beispiele: Erweiterung eines bestehenden Bank-Systems um eine Schnittstelle zu einem Online-Banking-Zugangskanal oder um eine neue regulatorische Vorgabe etc.

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

Mode 2 – Exploration ist optimal für unbekannte Bereiche, um neue Themen explorativ und experimentell zu lösen. Diese Initiativen beginnen oft mit einer Hypothese, die innerhalb eines Prozesses mit kurzen Iterationen entwickelt, getestet und angepasst wird, unter Zugrundelegung/Annahme eines minimal tragfähigen Produktansatzes (Minimum Viable Product ➞ MVP). Für IT-Projekte bieten sich agile Vorgehensmodelle an. Da «explorativ», können in diesen Projekten auch Mitarbeiter ohne spezifisches Knowhow zum Einsatz kommen. Beispiel: Erstellung eines neuen «Crowd Funding»-Features im FinTec.-Umfeld

Abbildung 5: Bimodale IT

Innovate Mode 2 Digital Differentiate Mode 1 Legacy Run

Mode 1 Legacy

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

4.14 Dev ops Unter DevOps versteht man im Wesentlichen eine optimierte Zusammenarbeit von Entwicklung und Betrieb, die zu einer schnelleren und fehlerfreieren Softwareauslieferung führen soll. Damit soll der klassische Konflikt zwischen einer möglichst kurzfristigen und zeitnahen SW-Entwicklung sowie der eher starren, risikobasierten Haltung des Betriebs aufgelöst/reduziert werden. Starre, langfristige Release-Zyklen sollen durch kurze, zeitnahe Zyklen ersetzt werden. Dabei soll eine gleichbleibend hohe Qualität der ausgelieferten Software sichergestellt werden. Dies soll über ein durchgängig agiles Vorgehen erzielt werden: • Die agile Softwareentwicklung (Extreme Programming, Scrum) basiert auf dem generischen Ansatz des RAD-Modells, mit der Zielsetzung einer Beschleunigung der Softwareentwicklung. • Der Einsatz agiler Methoden im Softwareentwicklungsprozess soll ein Mehr an erforderlicher Flexibilität bringen und die Möglichkeit schneller Anpassung an neue Anforderungen ermöglichen. • Codeentwicklung und -ausführung sollten eng miteinander verzahnt sein, damit Fehler zeitnah gefunden und behoben werden können. • Continuous-Integration-(CI-) und Continuous-Delivery-Werkzeuge (wie Jenkins) sollen automatisierte Software-Builds mit dem Ziel ermöglichen, eine höhere Code-Qualität und Widerstandsfähigkeit im Fehlerfall zu erhalten.

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

Code

ea s

Re l

Build

Test

Operations

Operate

an Pl

Abbildung 6: Zusammenspiel von Development & Operations

Development

Deploy

Monitor

4.15 SHIFT LEFT «Shift Left» soll dabei unterstützen, möglichst frühzeitig Fehler zu finden oder zu verhindern (Early Error Detection). Im Prinzip wird der Zeitpunkt des Testens vorgezogen (auf einem Zeitstrahl «nach links»).

Abbildung 7: «Shift Testing to the left»

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

Klassischer Shift Left (anhand V-Modell) Wie im Bild unten dargestellt, verschiebt der klassische Shift Left im V-Modell den Schwerpunkt des Testens nach «links unten». Der klassische Shift Left konzentriert sich somit bereits auf die Teststufen UnitTest und Integration-Test. Abbildung 8: Klassischer Shift Left User Needs Discovery

Operational Testing

verifies

User Requirements Engineering

Acceptance Testing

verifies Validation Verification

System Testing

System Integration Test

verifies

Design

Coding

Subsystem Integration Testing

Unit Testing

Tra

tio

verifies

Architekture Engineering

verifies

System Requirements Engineering

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

Agil/DevOps Shift Left Testing Abgeleitet aus dem V-Modell haben agile Projekte zahlreiche kurze Vs (a.k.a. Sprints). Die frühen, «kleinen» Vs befinden sich auf dem Zeitstrahl links von den korrespondierenden nachfolgenden «grösseren» Vs. Je früher mit dem Whitebox-Testen von den einzelnen Sprints begonnen wird, desto früher können Fehler gefunden werden. Dazu muss der Scope pro Sprint festgelegt werden!

Abbildung 9: Agile Shift Left Testing User Needs Discovery

Operational Testing

verifies

User Requirements Engineering

Acceptance Testing

verifies Validation Verification

System Requirements Engineering

System Testing

verifies

Architekture Engineering

System Integration Test

verifies

Design

Coding

Subsystem Integration Testing

Unit Testing

Agile/DevOps Shift Left

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

4.16 CYNEFIN FRAMEWORK Cynefin ist das walisische Wort für Habitat (Lebensraum). Das Cynefin Framework wurde ursprünglich im Kontext mit Wissensmanagement und Organisationsstrategie entwickelt. Bis 2002 hatte es sich so weit entwickelt, dass es die Theorie komplexer adaptiver Systeme beinhaltete und zu einem allgemeinen Strategie-Modell wurde. Das Framework soll Entscheider dabei unterstützen, die Situation richtig einzuschätzen sowie ein angemessenes Vorgehen zu wählen. Cynefin bietet die folgenden fünf Domänen (Kontexte) zur Entscheidungsfindung an: Obvious Beziehung zwischen Ursache und Wirkung ist für alle offensichtlich. Die Herangehensweise ist hier «Sense – Categorise – Respond», und es können bewährte Praktiken angewendet werden (best practices). Complicated Beziehung zwischen Ursache und Wirkung erfordert eine Analyse, eine andere Form der Prüfung und/oder die Anwendung von Fachwissen. Hier geht man mittels «Sense – Analyze – Respond» heran, und es können passende Praktiken angewendet werden (good practices). Complex Beziehung zwischen Ursache und Wirkung kann nur im Nachhinein wahrgenommen werden, aber nicht im Voraus. Hier ist der Ansatz «Probe – Sense – Respond». Passende Praktiken zeichnen sich nicht sofort ab/müssen herausgearbeitet werden/erscheinen erst im Laufe des Prozesses (emergent practice).

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

Chaotic Es gibt keine Beziehung zwischen Ursache und Wirkung auf Systemebene. Hier ist der Ansatz «Act – Sense – Respond». Es müssen erst noch neue Praktiken entwickelt werden (innovative practice). Unknown Unwissenheit/unterschiedliche Sichten/nicht zuordenbar, welche Art von Kausalität besteht. Der Ausweg aus diesem Dilemma besteht darin, die Situation «in ihre Bestandteile herunterzubrechen» und jede entstandene Komponente einem der vier anderen Bereiche zuzuordnen.

Abbildung 10: Domänen des Cynefin Frameworks

din

an rst

Stan

dard

Complicated

isati

Knowable, Unfamiliar

on Obvious

Known, Familiar

Complex Unknown

Disorder

Loss Contof rol

Chaotic

Unknowable

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

«Tour de Domaines» Im Uhrzeigersinn geht es vom völlig Unbekannten zum Bekannten, vom Chaotischen zum Komplexen, vom Komplexen zum Komplizierten, vom Komplizierten zum Bekannten. Aufgrund von unzureichender Wartung, Nachlässigkeit, ggf. sogar verzerrter Wahrnehmung oder Selbstgefälligkeit kann dagegen ein bekannter, «wohlgeordneter» Bereich in eine Katastrophe münden. Der Zeiger pendelt dann vom Bekannten ins Chaotische. Die Bewegung kann auch gegen den Uhrzeigersinn gehen, weil Mitarbeiter gehen, Know-how verloren geht oder neue Generationen die aufgestellten Regeln und Prozesse infrage stellen.

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

Abbildung 11: Die Domänen des Cynefin Frameworks mal anders erklärt

Complex

Complicated

Was war zuerst da, das Huhn oder das Ei?

Durch gründliche Analyse haben wir ermittelt, dass der Zustand, der üblicherweise unter «Ei» verstanden wird, offenkundig dem Zustand des Huhnes vorausgeht.

Sind das Huhn und das Ei unterschiedlich und gibt es wirklich Hühner?

Das Ei war vor dem Huhn da.

Chaotic

Obvious

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

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

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

Sprint-Demos, Akzeptanztest Change Requests, Bugfixes, Wünsche

Unit-Test, automatisiert Sprint 1

Sprint 2

Sprint 3

Sprint 4

Sprint 5

Sprint 6

Sprint 7

Sprint 8

Sprint 9

Sprint 10

Feedback

Testautomatisierung, Explorativer Test

Release Testaktivitäten Testfälle total

Testdesign, manueller Regressionstest automatisierte Testfälle

Feature Complete

Abbildung 12: Testmanagement im agilen Umfeld

Abbildung 12 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. Copyright © 2017, bbv Software Services AG

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

Anpassungsfähigkeit Installierbarkeit Austauschbarkeit

Übertragbarkeit (Portability)

Funktionalität (Functional suitability)

Vollständigkeit Korrektheit Angemessenheit

Modularität Wiederverwendbarkeit Analysierbarkeit Modifizierbarkeit Prüfbarkeit

Effizienz (Performance efficiency)

Wartbarkeit (Maintainability)

Vertraulichkeit Integrität Nachweisbarkeit Verantwortlichkeit Authentizität Ausgereiftheit Verfügbarkeit Fehlertoleranz Wiederherstellbarkeit

Antwortzeitverhalten Ressourcenverbrauch Kapazität

ISO 25010 Sicherheit (Security)

Zuverlässigkeit (Reliability)

Kompatibilität (Compatibility)

Benutzbarkeit (Usability)

Koexistenz Interoperabilität

Angemessenheit Erkennbarkeit Erlernbarkeit Bedienbarkeit Fehlertoleranz ggü. Anwenderfehlern Ästhetik der Benutzeroberfläche Barrierefreiheit

Abbildung 13: 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. Zur Auswahl entsprechender Qualitätsziele eignet sich beispielsweise die Qualitätsnorm ISO 25010 (siehe Abbildung 13).

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

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 14: Die agilen Test-Quadranten nach Crispin/Gregory

Automatisiert

Kundenorientiert

Funktionale Tests Beispiele Story Tests Simulationen Prototypen

Explorativer Test Szenarien Usability Testing UAT (User Akzeptanz Test) Alpha/Beta Test

Unit Tests Komponenten Tests

Performance & Load Test Security Test «-ility» – Tests

Q2Q3 Q1Q4 Technologieorientiert

Manuell

Produkt prüfen

Team unterstützen

Automatisiert und manuell

Werkzeuge

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 Copyright © 2017, bbv Software Services AG

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

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 («agiler» Test Manager) ausserhalb des Scrum Teams erstellt.

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

Abbildung 15: 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 SprintBacklog-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-BugStrategie). 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.

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

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?

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

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).

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

7 TESTAKTIVITÄTEN IN EINER ITERATION

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

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 ReleasePlan, 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 ReleasePlan wird vom Product Owner in jedem Sprint aktualisiert. Copyright © 2017, bbv Software Services AG

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

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.

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

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 Testers 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.

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

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 AcceptanceTests 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.

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

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 User-Akzeptanz-Test (UAT), finale Abnahmetests, Regressionstests oder nicht funktionale Tests, 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.

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

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.

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

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.

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

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.

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

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.

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

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 gerade 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.

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

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 noch rechtzeitig 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.

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

9 Anhang

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

9.1 Referenzen [1] Lisa Crispin, Janet Gregory, Agile Testing, Addison-Wesley, 2009 [2] Mike Cohn, Succeeding with Agile, Addison-Wesley, 2009 [3] Gartner IT Glossary 2017 [4] Brian Fitzgerald, Klaas-Jan Stol: Continuous Software Engineering – A Roadmap and Agenda. In: Journal of Systems and Software, 4. Juli 2015 doi: 10.1016/j.jss.2015.06.063 [5] DevOpsDays 2009 Ghent. In: devopsdays.org. 2009, abgerufen am 17. Februar 2016 (englisch) [6] Nayan B. Ruparelia: Software Development Lifecycle Models. In: ACM SIGSOFT Software Engineering Notes 35 No. 3. 10. Januar 2010, abgerufen am 24. Februar 2016 (PDF; 345 KB, englisch) [7] Donald Firesmith (23 March 2015). «Four Types of Shift Left Testing». Retrieved 27 March 2015 [8] Snowden, David J.; Boone, Mary E. (November 2007). «A Leader‘s Framework for Decision Making». Harvard Business Review, 69–76 [9] Williams and Hummelbrunner (2010), 165 [10] Stewart, Thomas (November 2002). «How to Think With Your Gut». Business 2.0 (1–5), 4–5

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.

Unsere Booklets und vieles mehr finden Sie unter www.bbv.ch/publikationen

Making Visions Work. www.bbv.ch · info@bbv.ch