Booklet SOFTWAREQUALITÄT IN AGILEN PROJEKTEN · der agile (embedded) Tester im Scrum Team nicht in der Lage ist (z. B. End-to-End-Tests). Da der Begriff «Test Manager» mit klassi

Copyright © 2017

bbv Software Services AG

Bo

ok

let SOFTWAREQUALITÄT IN

AGILEN PROJEKTEN

SOFTWAREQUALITÄT IN AGILEN PROJEKTEN

2 Copyright © 2017, bbv Software ServiCeS ag

kontakt Schweiz

bbv Software Services AG

Blumenrain 10

6002 Luzern

Telefon: +41 41 429 01 11

E-Mail: [email protected]

kontakt Deutschland

bbv Software Services GmbH

Agnes-Pockels-Bogen 1

80992 München

Telefon: +49 89 452 438 30

E-Mail: [email protected]

PROFITIEREN SIE vON UNSERER ERFAhRUNG!

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.

CopyRIGHt © 2017, BBV SoFtwARe SeRVICeS AG 3

1 Einleitung 5

2 Agile Softwareentwicklung 7

3 Rollen und Verantwortlichkeiten 9

4 Begrifflichkeiten rund um den Test 14

4.1 Automatisierte Regression 15

4.2 Test-Driven Development (TDD), Test-First 15

4.3 Acceptance-Test-Driven Development (ATDD) 17

4.4 Behaviour-Driven Development (BDD) 17

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

4.6 Model-Driven Software Development (MDSD) 19

4.7 Automatisierungsstrategie 20

4.8 Unit-/Komponententest 21

4.9 Acceptance-Test/Api-Layer-Tests 21

4.10 Systemtest/Gui-Test 21

4.11 Exploratives Testen 22

4.12 Automatisierung einer bestehenden Lösung 23

4.13 Bimodale IT 24

4.14 DevOps 26

4.15 Shift Left 27

4.16 Cynefin Framework 30

5 Testplanung 34

5.1 Qualitätsziele 36

5.2 Teststrategie 37

5.3 Testplan 38

5.4 Teststatusreport 39

6 Profil des agilen Testers 40

7 Testaktivitäten in einer Iteration 42

INhALT

SoFtwAReQUAlItÄt IN AGIleN pRoJekteN

SoFtwAReQUAlItÄt IN AGIleN pRoJekteN

7.1 Release-Planung und Pre-Planning 43

7.2 Iterationsplanung 45

7.3 Umsetzung 46

7.4 The End Game 47

7.5 User-Akzeptanz-Test (UAT) 48

7.6 Feedback 49

8 Erfolgsfaktoren 50

8.1 Das ganze Team ist verantwortlich 51

8.2 Sammeln und liefern Sie Feedback 51

8.3 Automatisieren Sie Regressionstests 51

8.4 Behalten Sie den Überblick 52

8.5 Führen Sie bei Bedarf Ruhesprints ein 52

8.6 Nutzen Sie agile Kernpraktiken 52

8.7 Binden Sie den Kunden mit ein 53

8.8 Seien Sie als agiler Tester frühzeitig dabei 53

9 Anhang 54

9.1 Referenzen 55

4 CopyRIGHt © 2017, BBV SoFtwARe SeRVICeS AG


5Copyright © 2017, bbv Software ServiCeS ag

1 EINLEITUNG

Software ist in unserer modernen Gesellschaft nicht

mehr wegzudenken. Verkürztes time-to-Market bei

hoher Softwarequalität sind inzwischen entscheiden-

de 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 stand-

zuhalten. Iterative (halb agile) Modelle, wie z. B. das

Spiralmodell oder Rational Unified process (RUp),

verfeinern und ergänzen schrittweise die grobe Aus-

gestaltung des Gesamtsystems durch kurze wieder-

holungen 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 verzeich-

nen. Der Auftraggeber erhält regelmässig in kurzen

Zyklen lauffähige und getestete «Softwarebausteine»,

bewertet diese und kann situationsabhängig An-

passungen vornehmen lassen. Somit kann er binnen

kürzester Zeit auf Marktveränderungen reagieren

oder sich bewusst wettbewerbsvorteile verschaffen.



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 Entwicklungspro-

zesse unter Beachtung des agilen Manifests und der Anwendung

agiler Prinzipien auf das Testen, wie schnelles Feedback, hoher Auto-

matisierungsgrad, 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 ge-

samte agile Team verteilt wird.

Insbesondere bei Tests, die häufig wiederholt werden müssen, wird

Testautomation in Form von Regressionstests inklusive nicht funktio-

naler 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) durch-

geführt werden. Dabei reicht es nicht aus, dass Entwickler nur auto-

matisierte 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 explora-

tive Tests. Dies erfordert den sinnvollen Einsatz geeigneter Testverfah-

ren, eine gute Test-/Iterations- und Release-Planung und hohe Skills des

agilen Testers.

Mit diesem Booklet sollen die wesentlichen Highlights und Erfolgs-

faktoren des Testens in agilen Projekten am Beispiel des Vorgehens-

modells Scrum zusammengefasst werden.



2 AGILE SOFTWARE- ENTWIcKLUNG

Ziel der agilen Softwareentwicklung ist es, sich mehr

auf die zu erreichenden ergebnisse (den «outcome»)

der Softwareentwicklung zu konzentrieren. Früh-

zeitig 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 ver-

waltet. 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 enginee-

ring-praktiken wie test-Driven Development (tDD),

extreme programming (Xp) und Continuous Integra-

tion (CI) unterstützen dieses Vorgehen, sodass durch

frühe Releases von kernfunktionalität ein schneller

Return of Investment (RoI) erreicht werden kann.



Sprint Start Sprint End

Sprint Planning

Daily Scrum

Sprint Retrospective

Sprint Review & Demo

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 Plan-

ning) 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 Verbesse-

rungsvorschläge werden vom Team nach der Demo in einer Review-

Sitzung (Sprint-Retrospektive) diskutiert.



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 Zusammen-

arbeit entsteht eine starke Bindung zwischen

kunde, produkt und entwicklungsteam.



Stakeholder(Kunde)

Team & Scrum

Product Owner

Abbildung 2: Rollen und Verantwort-

lichkeiten

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 Funktions-

umfang und Benutzbarkeit des zu erstellenden Produkts.

Der product owner ist für den Erfolg der Produktentwicklung ver-

antwortlich. Ihm allein obliegt die Entscheidung über das Produkt,

dessen Funktionalitäten und die Reihenfolge der Implementie-

rung. So balanciert er Eigenschaften, Auslieferungszeitpunkte und

Kosten. Als Produktverantwortlicher hält er regelmässig Rück-



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 Sprint-

ziel 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ünsch-

ten 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 verein-

barten 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 ver-

schiedenen 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 verschwim-

men auch die Grenzen zwischen Entwickler und Tester. Durch Test-



aktivitäten soll die Entwicklung des Systems durch schnelles Feed-

back abgesichert werden. Die früher angestrebte Unabhängigkeit

zwischen Entwickler und Tester wird zugunsten der engen Zusam-

menarbeit 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 Vorgehens-

modellen anzutreffen. Generell basiert seine Arbeit auf star-

ren Teststufen, Quality Gates und definierten Testkonzepten.



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 klassi-

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



4 BEGRIFFLIchKEITEN RUNd UM dEN TEST



4.1 AUTOMATISIERTE REGRESSION

Während des Sprints müssen permanent automatisierte Regressi-

onstests lauffähig sein, um als «Sicherheitsnetz» bei Codeänderun-

gen und Refactorings zu dienen. Weil die zu testende Funktionali-

tä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 Funktio-

nalität gewissenhaft manuell zu überprüfen. Die Automatisierung

von Testfällen löst dieses Problem und ermöglicht es, diese be-

liebig oft auszuführen. Dies gibt dem Tester Freiraum, die Anwen-

dung zusätzlich mit explorativen Tests zu prüfen. Nicht nur Unit-

und Integrationstests, sondern auch System- und Akzeptanz-

tests 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 entwi-

ckelte Softwareteile noch nicht auf Systemebene getestet wer-

den können (was häufig vorkommen kann), muss für den System-

test 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 ausge-



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 «auf-

geräumt». Überflüssiger, duplizierter Code wird entfernt oder

nach verbindlichen Code-Konventionen ausgerichtet.

Im Gegensatz zu klassischen Vorgehensweisen wie Wasserfall-

oder V-Modell hat TDD den Vorteil, dass durch viele kleine auto-

matisierte 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 betrach-

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



4.3 AccEpTANcE-TEST-DRIvEN DEvElOpMENT (ATDD)

Die akzeptanztestgetriebene Entwicklung (ATDD) ähnelt zwar der

testgetriebenen Entwicklung (TDD), ist jedoch eher ein Kommunika-

tionswerkzeug 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änd-

lich sein. Oft werden die testgetriebenen Tests von den akzeptanz-

getriebenen Tests abgeleitet.

Fehler in den funktionalen/nicht funktionalen Anforderungen kön-

nen 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 Spra-

che vorgibt, in welcher Businessprozesse beschrieben werden. So

wird die Beschreibung eines Features durch ein oder mehrere Bei-

spiele, die das Verhalten korrekt darstellen, verdeutlicht und über

diese getestet. Konkret heisst dies, dass im Prinzip auch Stakeholder

aus der Managementebene entsprechende Anforderungen definie-

ren 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 ver-

sierte 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:



«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 verbes-

sere die Kommunikation.

• Übernimm diese Techniken den ganzen Weg hinunter bis zu den

tiefsten Ebenen der Abstraktion der Software, wobei ein besonde-

res 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 ausge-

fü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 Abstraktions-

ebene 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 An-

forderungen analysieren

• Wiederkehrende Aktionen und Abläufe dann in Keywords kapseln



Ein einfaches Keyword (eine Aktion auf einem Objekt) wäre z. B. «Ein-

gabe 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 Wieder-

verwendbarkeit sowie der Steigerung der Effizienz von Soft-

wareentwicklungen. 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 Software-

entwicklungsprozesses. 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 Gene-

rierung des finalen Systems. Gemäss einer dreistufigen Modellhierar-

chie werden Systemanforderungen in formale Modelle abstrahiert,

Modelle zu weiteren Metamodellen und schliesslich Metametamo-

delle automatisch zu ausführbarem Code transformiert.

MDSD bietet die Vorteile, dass sich die Abstraktionsebene für

das zu spezifizierende System detaillierter darstellt, eine durch-

gängige Kommunikation durch domänenspezifische Sprachen

(DSLs) möglich ist und sich die Effizienz bei der Software-

erstellung durch die automatisierten Transformationen der er-

stellten Modelle bis zum generierten Code steigern lässt.

Gleichzeitig verringern Modelle die Komplexität in Design und



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

Automatisierungsaktivitäten über alle «Teststufen».

auto

mat

ical

ly e

xecu

ted

man

ual

ly e

xecu

ted

dri

ve d

evel

op

men

t

pro

vid

e ac

cep

tan

ce a

nd

reg

ress

ion

tes

ts

ManualTesting

ExploratoryTesting

System Acceptance Testsand

Constraints Tests

Executable Specifications –Acceptance Test Driven Development

Unit Test – Test Driven Development

Integration Tests (3rd-party components)

test

s n

ot

pra

ctic

al f

or

auto

mat

ion

fin

d g

aps

Abbildung 3: Die agile Testpyramide



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 Ausga-

be aufgelistet und ausführbar. Mit geeigneten Entwicklungswerkzeugen

können diese in einer formalen Form spezifiziert, festgehalten und schluss-

endlich 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 Wartungs-

Die agile Testpyramide, angelehnt an die Automatisierungspyrami-

de nach Mike Cohn, stellt auf einfache Weise dar, wie und wo sich

die Tests und Automatisierungsaufgaben in einem agilen Projekt ver-

teilen (Abbildung 3). Von zentraler Bedeutung ist, dass automati-

sierte 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 verschie-

dener Teststufen ausführt, bildet dafür eine unerlässliche Grundlage.



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 Test-

stufen sehr lange dauert. Die Anzahl an GUI-Tests sollte daher mög-

lichst 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 Vorga-

ben, 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. Erfahrungs-

gemäss kommt exploratives Testen im Scrum Team besonders gut

an, da es über die üblichen vorgegebenen Testpläne und Done-

Kriterien hinausgeht.

Exploratives Testen ist simultanes Lernen, Testdesign und Testaus-

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



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 Projekt-

methoden trifft man meist folgende Situation an: Für den

bestehenden Code existieren keine oder kaum Unit-Tests, die Archi-

tektur 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 ver-

sehen 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 Ver-

teilung der Testfälle über Teststufen entstehen, die in der Anzahl der

Gewichtung der Automatisierungspyramide entsprechen wird.

GUI-Tests für Hauptfunktionen

Keine Automatisierung

Unit-, API- und GUI-Tests

Auf- und Ausbau der Testautomatisierung

Abbildung 4: Umsetzung der Automatisierungsstrategie



4.13 BIMODAlE IT

Der Begriff «Bimodale IT» umfasst im Wesentlichen den Spannungs-

bogen, in dem sich die Unternehmen heute bez. ihrer bestehenden

Produkte und Dienstleistungen sowie der deutlich gestiegenen Anfor-

derungen des Marktumfelds im Zusammenhang mit Innovation, Digi-

talisierung und «Time-to-Market» von neuen Produktideen bewegen.

Aus IT-Sicht gibt es auf der einen Seite die bestehenden, gut bekann-

ten, bewährten, ggf. aber auch schwerfälligen Systeme und Techno-

logien 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 unterschiedli-

chen, aber kohärenten Ansätzen Predictability (Vorhersehbarkeit, Be-

rechenbarkeit, Planbarkeit) und Exploration (Erforschung, Erkundung).

Mode 1 – predictability ist optimal für Bereiche, die bereits gut ver-

standen, 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 (auf-

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



Mode 2 – exploration ist optimal für unbekannte Bereiche, um neue

Themen explorativ und experimentell zu lösen. Diese Initiativen begin-

nen oft mit einer Hypothese, die innerhalb eines Prozesses mit kurzen

Iterationen entwickelt, getestet und angepasst wird, unter Zugrun-

delegung/Annahme eines minimal tragfähigen Produktansatzes (Mini-

mum Viable Product ➞ MVP).

Für IT-Projekte bieten sich agile Vorgehensmodelle an. Da «explorativ»,

können in diesen Projekten auch Mitarbeiter ohne spezifisches Know-

how zum Einsatz kommen.

Beispiel: Erstellung eines neuen «Crowd Funding»-Features im

FinTec.-Umfeld

Innovate

Differentiate

Run

Mode 1Legacy

Mode 1Legacy

Mode 2Digital

Abbildung 5: Bimodale IT



4.14 DEv OpS

Unter DevOps versteht man im Wesentlichen eine optimierte Zusam-

menarbeit von Entwicklung und Betrieb, die zu einer schnelleren und

fehlerfreieren Softwareauslieferung führen soll. Damit soll der klassi-

sche 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-Zyk-

len sollen durch kurze, zeitnahe Zyklen ersetzt werden. Dabei soll eine

gleichbleibend hohe Qualität der ausgelieferten Software sicherge-

stellt 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 -ausführung sollten eng miteinander ver-

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



Abbildung 6: Zusammenspiel von

Development & Operations

Development Operations

Monitor

DeployCode

Test

Relea

seB

uild

Op

erate

Plan

4.15 ShIFT lEFT

«Shift Left» soll dabei unterstützen, möglichst frühzeitig Fehler zu fin-

den oder zu verhindern (Early Error Detection). Im Prinzip wird der Zeit-

punkt des Testens vorgezogen (auf einem Zeitstrahl «nach links»).

Abbildung 7: «Shift Testing to the left»



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 klas-

sische Shift Left konzentriert sich somit bereits auf die Teststufen Unit-

Test und Integration-Test.

Abbildung 8: Klassischer Shift Left

User NeedsDiscovery

User RequirementsEngineering

System RequirementsEngineering

ArchitektureEngineering

Design

Coding

OperationalTesting

AcceptanceTesting

SystemTesting

SubsystemIntegration

Testing

Unit Testing

SystemIntegration

Test

verifies

verifies

verifies

verifies

verifies

Validation

Verification

Trad

ition

al S

hift

Lef

t



User NeedsDiscovery

User RequirementsEngineering

System RequirementsEngineering

ArchitektureEngineering

Design

Coding

OperationalTesting

AcceptanceTesting

SystemTesting

SubsystemIntegration

Testing

Unit Testing

SystemIntegration

Test

verifies

verifies

verifies

verifies

verifies

Validation

Verification

Agile/DevOps Shift Left

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



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 so-

wie ein angemessenes Vorgehen zu wählen. Cynefin bietet die folgen-

den 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 Fachwis-

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



Chaotic

Es gibt keine Beziehung zwischen Ursache und Wirkung auf System-

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

Disorder

ChaoticUnknowable

ComplexUnknown

ObviousKnown, Familiar

ComplicatedKnowable, Unfamiliar

Understanding Standardisation

Loss of Control



«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 be-

kannter, «wohlgeordneter» Bereich in eine Katastrophe münden. Der

Zeiger pendelt dann vom Bekannten ins Chaotische.

Die Bewegung kann auch gegen den Uhrzeigersinn gehen, weil Mit-

arbeiter gehen, Know-how verloren geht oder neue Generationen die

aufgestellten Regeln und Prozesse infrage stellen.



Abbildung 11: Die Domänen des

Cynefin Frameworks mal anders erklärt

Chaotic

Complex

Obvious

Complicated

Was war zuerst da,das Huhn oder das Ei?

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

Das Ei war vor dem Huhn da.

Durch gründliche Analysehaben wir ermittelt, dass derZustand, der üblicherweiseunter «Ei» verstanden wird,offenkundig dem Zustand desHuhnes vorausgeht.



5 TESTPLANUNG

Auch im leichtgewichtigen agilen Umfeld macht

es Sinn, sich teststrategie und testplan zurecht-

zulegen. 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 ge-

schehen?



Abbildung 12 verdeutlicht die Verteilung der Testaufwände über meh-

rere Iterationen (Sprints) zwischen Kunde, Programmierer und Tester.

Durch Testautomatisierung wächst zwar die Gesamtanzahl der Test-

fä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 Um-

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

Testautomatisierung, Explorativer Test Release Testaktivitäten

Unit-Test, automatisiert

Testdesign, manueller Regressionstest

automatisierte Testfälle

Sprint-Demos, Akzeptanztest

Testfälle total

Sprint 1

Feedback

Sprint 2

Feedback

Sprint 3

Feedback

Sprint 4

Feedback

Sprint 5

Feedback

Sprint 6

Feedback

Sprint 7

Feedback

Sprint 8

Feedback

Sprint 9

Feedback

Sprint 10

Feedback

Change Requests, Bugfixes, Wünsche

Test

ing

Pro

gra

mm

ieru

ng

Ku

nd

ente

am

Feature Complete

Abbildung 12: Testmanagement im agilen Umfeld



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 beispiels-

weise die Qualitätsnorm ISO 25010 (siehe Abbildung 13).

Abbildung 13: Qualitätsziele nach ISO 25010

AnpassungsfähigkeitÜbertragbarkeit

(Portability)Installierbarkeit

Austauschbarkeit

Wiederverwendbarkeit

Analysierbarkeit

Modifizierbarkeit

Prüfbarkeit

Modularität

Vertraulichkeit

Integrität

Nachweisbarkeit

Verantwortlichkeit

Authentizität

Ausgereiftheit

Verfügbarkeit

Fehlertoleranz

Wiederherstellbarkeit

Wartbarkeit(Maintainability)

Sicherheit(Security)

Zuverlässigkeit(Reliability)

Funktionalität(Functional suitability)

Effizienz(Performance efficiency)

Kompatibilität(Compatibility)

Benutzbarkeit(Usability)

Vollständigkeit

Korrektheit

Angemessenheit

Antwortzeitverhalten

Ressourcenverbrauch

Kapazität

KoexistenzInteroperabilität

Angemessenheit Erkennbarkeit

Erlernbarkeit

Bedienbarkeit

Fehlertoleranz ggü. Anwenderfehlern

Ästhetik der Benutzeroberfläche

Barrierefreiheit

ISO 25010



5.2 TESTSTRATEGIE

Auch im agilen Testen sollten Überlegungen zu einzelnen Testmetho-

den, 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.

Kundenorientiert

Technologieorientiert

Team

un

ters

tütz

en

Pro

du

kt p

rüfe

n

Funktionale TestsBeispiele

Story TestsSimulationenPrototypen

Explorativer TestSzenarien

Usability TestingUAT (User Akzeptanz Test)

Alpha/Beta Test

Performance & Load TestSecurity Test

«-ility» – Tests

Unit TestsKomponenten Tests

ManuellManuellAutomatisiert und manuell

WerkzeugeAutomatisiert

Q1Q4Q2Q3

Abbildung 14: Die agilen Test-Quadran-ten nach Crispin/Gregory

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 Test-

arten und Vorgehensweisen zu bestimmen. Welche Testarten



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 abzu-

schliessen («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 dynami-

schen High-Level-Testplans wertvoll sein, damit team-/sprintüber-

greifende Testaktivitäten stets berücksichtigt werden. Generell wird

der Testplan von einem Test Master («agiler» Test Manager) ausser-

halb des Scrum Teams erstellt.



5.4 TESTSTATUSREpORT

Für eine Iteration kann es genügen, Funktionalität und zu tes-

tende 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 erforderli-

che Akzeptanzkriterien existieren und alle Testfälle zu diesem Zeit-

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

Abbildung 15: Beispiel eines Teststatusreports



6 PROFIL dES AGILEN TESTERSIn einem idealen agilen Softwareprojekt gibt es

keine separate testabteilung mehr. ebenso ent-

fallen die klassischen testrollen wie test Manager,

test Analyst oder tester. Die dedizierte exklusi-

ve 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 kennt-

nisse 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 Test-

methoden 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 Planbar-

keit, Rückverfolgbarkeit, Nachweisbarkeit der Testaktivitäten,

systematisches Testen mit hoher Testabdeckung).



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öffentli-

chung 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öchst-

priorisierten 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 Ter-

mine 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än-

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



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 Arbeits-

aufwand 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 Entwicklungsauf-

wands 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 Program-

mier- 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 schnellst-

möglich mit der Realisierung konkreter Testfälle. Sind die Test-

fä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üh-

ren Programmierer einen Walkthrough bzw. eine Demonstration

gegenüber dem Tester durch («Show me»), bevor Code ein-

gecheckt und explorativ und funktional getestet wird oder auto-

matisierte 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

User-Akzeptanz-Test (UAT), finale Abnahmetests, Regressionstests

oder nicht funktionale Tests, wie Load- und Performancetests,

durchzuführen respektive vor dem endgültigen Rollout abzu-

schliessen sind. Dokumentationen und Handbücher sind zu ver-

vollständigen.

In dieser letzten Phase vor dem Rollout sollte darauf verzichtet wer-

den, noch unkritische Fehler zu beheben oder neue Stories zu be-

ginnen, 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, Instal-

lationstests, 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 Deploy-

ments, 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 Bedingun-

gen 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äts-

aktivitä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.



8 ERFOLGSFAKTOREN

Nachfolgend sind die aus Sicht der bbv Software

Services AG wichtigsten Faktoren für ein erfolg-

reiches 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 Kundenanforde-

rungen 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 Sicher-

heitsnetz, 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.



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 Sonder-

fä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) einzu-

fü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 Teil-

funktion 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 Kun-

den, 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 Benutzerszena-

rien 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 Re-

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



9 ANhANG



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 Re-

view, 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

www.bbv.ch · [email protected]

MAKING vISIONS wORK.

Unsere Booklets und vieles mehr finden Sie unter

www.bbv.ch/publikationen

bbv Software Services AG ist ein Schweizer Soft-

ware- und Beratungsunternehmen, das kunden

bei der Realisierung ihrer Visionen und projek-

te unterstützt. wir entwickeln individuelle

Softwarelösungen und begleiten kunden mit

fundierter Beratung, erstklassigem Software

engineering und langjähriger Branchenerfah-

rung auf dem weg zur erfolgreichen lösung.

Documents

Booklet SOFTWAREQUALITÄT IN AGILEN PROJEKTEN · der agile (embedded) Tester im Scrum Team nicht in der Lage ist (z. B. End-to-End-Tests). Da der Begriff «Test Manager» mit klassi