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
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
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.
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
6 Copyright © 2017, bbv Software ServiCeS ag
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.
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
7Copyright © 2017, bbv Software ServiCeS ag
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.
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
8 Copyright © 2017, bbv Software ServiCeS ag
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.
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
9Copyright © 2017, bbv Software ServiCeS ag
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.
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
10 Copyright © 2017, bbv Software ServiCeS ag
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-
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
11Copyright © 2017, bbv Software ServiCeS ag
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-
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
12 Copyright © 2017, bbv Software ServiCeS ag
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.
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
13Copyright © 2017, bbv Software ServiCeS ag
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»).
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
14 Copyright © 2017, bbv Software ServiCeS ag
4 BEGRIFFLIchKEITEN RUNd UM dEN TEST
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
15Copyright © 2017, bbv Software ServiCeS ag
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-
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
16 Copyright © 2017, bbv Software ServiCeS ag
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).
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
17Copyright © 2017, bbv Software ServiCeS ag
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:
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
18 Copyright © 2017, bbv Software ServiCeS ag
«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
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
19Copyright © 2017, bbv Software ServiCeS ag
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
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
20 Copyright © 2017, bbv Software ServiCeS ag
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
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
21Copyright © 2017, bbv Software ServiCeS ag
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.
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
22 Copyright © 2017, bbv Software ServiCeS ag
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
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
23Copyright © 2017, bbv Software ServiCeS ag
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
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
24 Copyright © 2017, bbv Software ServiCeS ag
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.
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
25Copyright © 2017, bbv Software ServiCeS ag
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
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
26 Copyright © 2017, bbv Software ServiCeS ag
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.
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
27Copyright © 2017, bbv Software ServiCeS ag
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»
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
28 Copyright © 2017, bbv Software ServiCeS ag
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
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
29Copyright © 2017, bbv Software ServiCeS ag
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
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
30 Copyright © 2017, bbv Software ServiCeS ag
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).
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
31Copyright © 2017, bbv Software ServiCeS ag
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
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
32 Copyright © 2017, bbv Software ServiCeS ag
«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.
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
33Copyright © 2017, bbv Software ServiCeS ag
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.
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
34 Copyright © 2017, bbv Software ServiCeS ag
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?
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
35Copyright © 2017, bbv Software ServiCeS ag
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
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
36 Copyright © 2017, bbv Software ServiCeS ag
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
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
37Copyright © 2017, bbv Software ServiCeS ag
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
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
38 Copyright © 2017, bbv Software ServiCeS ag
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.
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
39Copyright © 2017, bbv Software ServiCeS ag
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
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
40 Copyright © 2017, bbv Software ServiCeS ag
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?
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
41Copyright © 2017, bbv Software ServiCeS ag
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).
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
42 Copyright © 2017, bbv Software ServiCeS ag
7 TESTAKTIvITÄTEN IN EINER ITERATION
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
43Copyright © 2017, bbv Software ServiCeS ag
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.
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
44 Copyright © 2017, bbv Software ServiCeS ag
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
45Copyright © 2017, bbv Software ServiCeS ag
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.
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
46 Copyright © 2017, bbv Software ServiCeS ag
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.
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
47Copyright © 2017, bbv Software ServiCeS ag
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.
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
48 Copyright © 2017, bbv Software ServiCeS ag
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.
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
49Copyright © 2017, bbv Software ServiCeS ag
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.
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
50 Copyright © 2017, bbv Software ServiCeS ag
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.
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
51Copyright © 2017, bbv Software ServiCeS ag
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.
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
52 Copyright © 2017, bbv Software ServiCeS ag
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.
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
53Copyright © 2017, bbv Software ServiCeS ag
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.
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
54 Copyright © 2017, bbv Software ServiCeS ag
9 ANhANG
SOFTWAREQUALITÄT IN AGILEN PROJEKTEN
55Copyright © 2017, bbv Software ServiCeS ag
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.