3. Agenda
Page 3
Line-Up
Die Welt steht doch nicht still!
Basis des Reports
Erste Zahlen und Trends
Scrum Rock‘s – Testing Suck‘s
1
2
3
4
5
Die Welt der Testwerkzeuge
Wissen – Das Lebenselixir unserer Unternehmen
Wohin geht es: Trends & Co
6
7
8
5. SwissQ ist…
… Initiator und Organisator des alljährlich stattfindenden Swiss
Testing Day – und neu auch des Swiss Requirements Day.
Page 5
6. Consulting
Übernahme von Test-
Aufgaben, Mobile und
New Media Testing
Management
Software
Testing
Aufbau und Optimierung
von Testorganisationen,
Mentoring, Ad Interim
Management
Academy
Aus- und Weiterbildung,
Konferenzen und Events,
Research and Development
SCENESwissQ Serviceprofil
Page 6
11. Basis des Reports
Page 11
Source
Umfrage bei über 1500 Software Tester der Schweiz
1:1 Gespräche mit ausgewählten Executives im Bereich Testing
Gespiegelt mit nationalen und internationalen Experten
16. Projektart- und grösse
Page 16
Etwas
über
die
Häl0e
der
Teilnehmenden
haben
auf
die
Frage
nach
der
Art
des
aktuellen
Projektes
Neu-‐Entwicklung
genannt.
Dies
spiegelt
sich
auch
in
der
Grösse
dieser
Projekte,
wo
für
je
etwa
30%
eine
Grösse
zwischen
500
Tsd.
bis
1
Mio.
bzw.
1
bis
5
Mio.
angegeben
wurde.
Gemessen
an
der
Medienpräsenz
ist
der
Anteil
an
Standard-‐So0ware
unerwartet
gering.
18. Projekterfolg
Page 18
Der
vielziPerte
Chaos
Report
der
Standish
Group
wird
o0
als
Mythos
bezeichnet,
der
auf
die
Schweiz
nicht
zutrifft.
Die
Umfrage
zeigt
jedoch
ein
sehr
ähnliches
Bild,
mit
nur
knapp
einem
Viertel
der
Projekte
die
in
Zeit,
in
Budget
und
mit
gewünschter
FunkPonalität
beendet
werden.
Interessant
ist
die
Tatsache,
dass
scheinbar
keine
Projekte
gestoppt
wurden,
was
jedoch
hinterfragt
werden
muss.
19. Ansehen des Testens
Page 19
Der
Stellenwert
des
TesPng
in
der
eigenen
OrganisaPon
wird
von
einem
Grossteil
als
sehr
hoch
bezeichnet.
Natürlich
hat
dies
auch
mit
der
Eigenwahrnehmung
der
Tester
zu
tun.
Es
ist
jedoch
unbestri[en,
dass
allgemein
Testen
an
Ansehen
gewinnt
und
als
eigenständige
Disziplin
aus
der
SW-‐
Entwicklung
nicht
mehr
wegzudenken
ist.
Einzig
in
der
höheren
Fachausbildung
wird
das
Thema
noch
sträflich
vernachlässigt.
20. Reifegrad des Testens
Page 20
Weniger
als
die
Häl0e
der
Befragten
bezeichnen
den
Reifegrad
der
TestakPvität
in
ihrem
Projekt
als
gut,
ein
paar
wenige
als
ausgezeichnet.
Dies
deckt
sich
mit
der
eher
negaPven
Beurteilung
der
Ausgangslage.
Trotz
gesPegenem
Ansehen,
passiert
es
immer
noch
allzu
o0,
dass
die
Tester
viel
zu
spät
involviert
werden
und
dass
die
So0ware
spät
und
in
ungenügender
Qualität
in
die
Testumgebung
ausgeliefert
wird.
21. Grundlagen Testfalldesign
Page 21
Tester
setzen
sich
als
Grundlage
für
das
Tes_alldesign
mit
Anforderungen
unter-‐
schiedlichster
Form
auseinander,
wobei
Prosa
und
Use
Cases
am
verbreitesten
sind.
O0mals
wird
auch
das
Altsystem
beigezogen.
Genauso
mannigfach
sind
auch
die
Herausforderungen
daraus
Tes_älle
abzuleiten,
die
eine
hohe
Testabdeckung
bieten
und
Fehler
finden,
die
in
der
ProdukPon
wehtun.
O0
wird
unterschätzt
wie
viel
Aufwand
in
die
Analyse
der
Anforderungen
invesPert
werden
muss.
22. Externe Ressourcen
Page 22
Bei
knapp
60%
werden
TestakPvitäten
durch
externe
Ressourcen
unterstützt.
Dabei
handelt
es
sich
meist
um
Personen,
die
vor
Ort
im
Unternehmen
oder
in
der
Schweiz
täPg
sind.
Bei
Ressourcen
die
vom
Ausland
täPg
sind
steht
Indien
im
Vordergrund.
Outsourced
TesPng
in
Osteuropa
findet
erstaunlich
wenig
sta[.
25. Einsatz agiler Methoden
Page 25
Agile
Vorgehen,
für
die
meisten
gleichbedeutend
mit
SCRUM
oder
SCRUM-‐ähnlichen
Methoden,
sind
in
aller
Munde
und
2/3
der
Teilnehmenden
geben
an,
dass
ihr
Unternehmen
bereits
Projekte
nach
einer
agilen
Vorgehensweise
durchführt
oder
für
die
nahe
Zukun0
plant.
Etwas
über
20%
arbeiten
denn
auch
bereits
in
einem
solchen
Projekt
mit.
Seitens
Entscheidungsträger
wird
der
Wert
von
SCRUM
anerkannt,
vorausgesetzt
es
wird
methodisch
korrekt
und
für
die
richPgen
Vorhaben
eingesetzt.
26. Scrum Rocks, Testing Sucks?!
Adrian Stoll
SwissQ Testing Trends & Benchmarking 2011
Zürich, 14. Juni 2011
27. Ziele der Präsentation
Wie ein Scrum Team von einer dedizierten Person für das Testing
profitiert
Warum ein Embedded Scrum Tester besser ist, als die
Testverantwortung auf das ganze Team zu verteilen
Was trägt ein Tester zu den Scrum Prozessen wie Daily Scrum,
Sprint Planning, Retrospective etc. bei
... und vor allem: Finden Sie heraus, weshalb Testing in Scrum
Spass macht, weil man involviert ist und schneller zum Ziel kommt
Page 27
28. Agenda
1. Scrum Testing in der Praxis
2. Warum Testing in Scrum rockt!
3. Scrum Testing im Detail – Techniken und Technologien
4. Lessons Learned
Page 28
29. SCENE
Adrian Stoll
Wirtschaftsinformatiker, Tester aus
Leidenschaft, Geek
Senior Consultant, SwissQ Consulting AG
Ihr Referent
Scrum-Erfahrung:
• Embedded Tester in 2 Siegerprojekten der
"Best of Swiss Web"-Awards
• Scrum Test Professional bei einer grossen
Versicherung
• Kursleiter "Testing
in Scrum"
Page 29
30. Agenda
1. Scrum Testing in der Praxis
2. Warum Testing in Scrum rockt!
3. Scrum Testing im Detail – Techniken und Technologien
4. Lessons Learned
Page 30
31. Blick auf die Vorgehensweisen
Page 31
ATST
Konzept Design High Level Test EinführungCode Low Level Test
Wasserfall
ST/AT ST/AT ST/AT ST/AT ST/AT ST/AT ST/AT ST/AT
S1 S2 S3 S4 S5 S6 S7 S8
Scrum
33. Embedded Scrum Tester
Gemeinsame Verantwortung:
"Alle" sind für das Testen verantwortlich Ist (High Level) Test Know-How
vorhanden?
Ist Testing wirklich unabhängig, objektiv?
Wie/wer verantwortet Bug-Fixing und
Retests?
Im Scrum Team wird Testing als gemein-
same Verantwortung wahrgenommen. Oft
werden Entwickler für das Testing zugeteilt,
was einige Risiken mit sich bringt:
Page 33
34. Embedded Scrum Tester
Ein Embedded Scrum Tester kann diese
Risiken minimieren:
Spezial-Wissen vorhanden
Unabhängig und „objektiv“
Fehler können umgehend behoben
werden (sehr kurze Feedback-Zyklen)
Gemeinsame Verantwortung:
"Alle" sind für das Testen verantwortlich
Embedded Tester:
Test durch einen unabhängigen
Spezialisten
Page 34
35. Agenda
1. Scrum Testing in der Praxis
2. Warum Testing in Scrum rockt!
3. Scrum Testing im Detail – Techniken und Technologien
4. Lessons Learned
Page 35
36. Why traditional Testing sucks
Frustrierend – Fehler zu finden, die offensichtlich sind
Undankbar – als Tester ist man bei Entwicklern oft unbeliebt
Stressig – bei Verzögerungen verkürzt sich meist die Testzeit
Eintönig – immer wieder dieselben Testfälle, repetitiv
Isoliert – als Tester kann man selten die Umsetzung beeinflussen
Page 36
37. Why Scrum Testing rocks
Motivierend – Raschere Testresultate, schnellere Bugfixes
Dankbar – Entlastung für Entwickler, positives Feedback
Kontrolliert – eingebetted in Scrum Planung und Zyklus
Abwechslungsreich – am Puls der (raschen) Weiterentwicklung
Involviert – Mitreden und Lösungsvorschläge erwünscht
Page 37
38. Agenda
1. Scrum Testing in der Praxis
2. Warum Testing in Scrum rockt!
3. Scrum Testing im Detail – Techniken und Technologien
4. Lessons Learned
Page 38
41. Techniken und Technologien
Entwicklung und Dokumentation von strukturierten (Regressions-) Testfällen
fortlaufend
Übersicht Regressions-Testcases
Stand per Sprint XX
Page 41
42. Beitrag des Testers in Scrum Prozessen
User Story Review in enger Zusammenarbeit mit dem Product Owner
Sprint Planning
Page 42
43. Beitrag des Testers in Scrum Prozessen
Abschätzen der Zeit, welche zum Testen von User Stories benötigt
wird und dafür sorgen, dass diese bei der Aufwandschätzung
berücksichtigt wird
Estimation Meeting
Page 43
44. Beitrag des Testers in Scrum Prozessen
(auch Daily Standup): Was habe ich gestern getestet, was teste ich
heute, wo hatte ich Probleme beim Testen?
Daily Scrum
Image: Danny (Danko) Kovatch
Page 44
45. Beitrag des Testers in Scrum Prozessen
Kennenlernen neuer Features vor dem Testing
(oder: bereits getestete Features selbst demonstrieren)
Sprint Review / Demo
Die Demo lief diesmal richtig flüssig und wie aus einem Guss.
Machte einen super-professionellen Eindruck, weiter so!
Page 45
46. Beitrag des Testers in Scrum Prozessen
Wo waren die Stolpersteine aus Tester-Sicht, was lief besonders
gut? Was kann man neu/anders machen?
Scrum Retrospective
Image: IT-Zynergy ApS
Page 46
47. Agenda
1. Scrum Testing in der Praxis
2. Warum Testing in Scrum rockt!
3. Scrum Testing im Detail – Techniken und Technologien
4. Lessons Learned
Page 47
48. Scrum Testing – Best Practices
Testing-Workflow im Scrum Tool einführen
Anforderungsbasiertes Testing anhand von User Stories
Der Entwickler schreibt ein "How to test" pro Story
Sprint-Planung und Fortschritt stetig überwachen
Tests möglichst rasch durchführen, Anhäufung von pendenten
Testfällen vermeiden
Nahe beim Team sein: Physisch präsent oder mithilfe von
elektronischen Kommunikationsmitteln
Integrationsfördernde Massnahmen zahlen sich aus: Anpassung an
Kleidung, Sprache, Arbeitszeiten, Gewohnheiten des Teams etc.
Page 48
49. Scrum Testing – Lessons learned
Scrum erfordert Disziplin!
Vorsicht vor "Technical Debts"!
Dokumentation wird häufig vernachlässigt
End-to-End Testing sauber planen
Scrum Testing und Remote Testing: Tolle Kombination!
Continous Integration Mechanismen nutzen
"Explodierende" Regressionstests
Page 49
50. Thank you for your
involvement
defending the
platform and the
work done.
Are you ready for the challenge?
Da wären wir nie
drauf gekommen.
Toll, was du
alles findest
euer team hat wirklich einen super job gemacht. die letzten
Tage sind wirklich weltmeisterlich verlaufen, an allen
ecken.
Eine echte
Unterstützung!
Ohne euch
hätten wir das
kaum
geschafft. du bist ne echte
testing maschine,
wir sind froh haben
wir dich dabei ;-)
Page 50
52. Tooleinsatz
Page 52
Nicht
überraschend,
haben
fast
80%
der
Befragten
ein
Testmanagement-‐
und
Defectmanagement-‐Tool
im
Gebrauch,
das
vollständig
implemenPert
ist
oder
wollen
dessen
Einsatz
erweitern.
SystemaPsches
Testen
ist
ohne
diese
Tools
fast
nicht
mehr
denkbar.
Auch
für
die
TestautomaPsierung
haben
rund
80%
der
Befragten
ein
Tool
im
Einsatz.
Hier
ist
allerdings
das
Verhältnis
zwischen
vollständig
Impl-‐emenPerten
Tools
und
solchen
deren
Einsatz
noch
erweitert
wird
genau
umgekehrt
im
Vergleich
zu
den
Managemen[ools.
53. Testautomatisierung
Page 53
Über
60%
der
Unternehmen
geben
an,
dass
weniger
als
10%
ihrer
(Regressions)
Tests
automaPsiert
sind.
Nur
9%
haben
über
50%
der
(Regressions)
Tests
automaPsiert.
Die
Zahlen
z e i g e n
v e r s t ä n d l i c h
a u f ,
w i e s o
TestautomaPsierung
als
einer
der
grössten
Trends
im
2011
gilt.
54. Wohin geht es mit den Testwerkzeugen
Page 54
FunktionalitätZukunft
Marktabdeckung
55. Testwerkzeuge
Slide-Set „removed“ aufgrund CopyRight Vorbehalten der Hersteller.
Bei Interesse nehmen Sie bitte direkt Kontakt mit SwissQ auf.
Page 55
56. Funktionalität – Fokus auf Risiken
Page 56
Eintrittswahrscheinlichkeit
hoch
>75%
Niedrig
<25%
Mittel
25%-75%
1
23
4
5
6
7
1. Bereich / Funktionalität / Req.
2. Bereich / Funktionalität / Req.
3. Bereich / Funktionalität / Req.
4. Bereich / Funktionalität / Req.
5. Bereich / Funktionalität / Req.
6. Bereich / Funktionalität / Req.
7. Bereich / Funktionalität / Req.
Auswirkung auf das Projekt (Termine, Kosten, Qualität)
niedrig hochmittel
58. Ausbildungsstand
Page 58
Fast
75%
der
Teilnehmenden
verfügen
über
ein
ISTQB
CerPfied
Tester
FoundaPon
Level
ZerPfikat
und
auch
die
Advanced
Level
ZerPfikate
sind
weit
verbreitet.
Gefragt
sind
daher
in
Zukun0
vor
allem
praxisbezogene
oder
verPefende
Kurse
wie
TesPng
in
Scrum
oder
ZerPfikate
in
angrenzenden
Themengebieten
wie
Requirements
Engineering,
Projekt
Management,
etc.
59. Theorie vs. Praxis
Page 59
‘Theory without practice is idle, practice without theory is blind’
Ancient Chinese Proverb
60. Wissens-Management
Wissen analysieren
Das wissen wir schon
Das sollten wir noch wissen
Wissen aufbauen
Theoretisches Wissen (ISTQB und ähnliche Kurse)
Wissen umsetzen
Praktisches Wissen (Best Practices, Austausch in einer Community)
Praxisbezogene Kurse, Seminare und Project-Coaching
Wissen pflegen
Wissen vertiefen
Wissen weiter geben und dokumentieren
Wissen in der Unternehmung halten
Page 60
62. Testdesign in der Praxis
Testideen
Fokus auf Qualitäts-
Dimension
• Funktionalität
• Zuverlässigkeit
• Benutzbarkeit
• Effizienz
• Änderbarkeit
• Übertragbarkeit
Testobjekte
Fokus auf Objektarten:
• Arbeitsabläufe
• GUIs
• Schnittstellen
• Batches
• Datenbanken
• ...
Logische
Testfälle
Fokus auf Teststufe und
Identifikation der
Testmethode
• Unit Test
• Integration Test
• System Test
• Acceptance Test
• Dynamisch
- Black Box
- White Box
- Unsystematisch
• Statisch
- Manuell
- Automation
Konkrete
Testfälle
Fokus auf Testfall-
Ermittlungsverfahren
• Äquivalenzklassen
• Grenzwertanalyse
• ...
• Knotenüberdeckung
• Kantenüberdeckung
• ...
• Exploratives Testen
• Intuitives Testen
• ...
• Technischer Review
• ...
Anforderungen
Fokus auf Testbarkeit:
• Verständlichkeit
• Eindeutigkeit
• Kein Design
• Konsistenz
Dieser Kurs beantwortet die Fragen aus der Praxis
• So testen Sie Ihre Anforderungen richtig
• So erarbeiten Sie die optimalste Testabdeckung
• So kommen Sie zum perfekten Testfall
• So vermeiden Sie Mehraufwand im Testing
Der neue Kurs aus der Praxis für die Praxis im Testalltag
Page 62
64. Projektumfeldanalyse
Qualität der Verbindung
+ Perfekt
o Normal
K Kritisch
Häufigkeit der Verbindungen
3 Intensiv
2 Mittel
1 Niedrig
0 nicht vorhanden
Projekt-
Leiter
Konstruktion
Berechnung
Kollegen
Allg.
Dev
Team 2.
Zulieferer
Kunde
Referenz
Berechnung
Versuch
Lead
Engineer
Abt. 1
Screen
Designer
RE-Unit
User
Abt. AB
DB
Intranet
Internet
FTL
Abt. 4
o/0.5
k/0.5
o/1
o/1
+/2
+/2
o/1
/0
+/1
+/3
+/2
+/2
+/2
+/3
+/1
+/3
Page 64
65. Kapazitätsplanung
Darstellung
der
Kapazitäten
nach
Kapazitätsstellen
des
Gesamtprojektes
(A)
und
zeitlichem
Verlauf
je
Kapazitätsstelle
(B,
C)
1
2
3
4
5
6
7
8
Jan
Feb
Mär
Apr
Mai
Jun
Jul
Aug
Sep
Okt
Nov
Dez
Jan
Feb
Mär
Apr
Mai
Jun
Jul
Aug
Sep
Okt
Nov
Dez
Kapazität
(Stelle
1)
Kapazität
(Gesamtprojekt)
Kapazität
(Stelle
2)
Kapazitätsstelle
B
C
Max.
Max.
Max.
A
Page 65
70. Outsourcing
Strategie
Neue
Technologien
Head Count
Kosten-
reduktion
Re-Organisation
Far Environment
Elemente, auf welche wir
nur reagieren können
(jedoch nicht beeinflussen).
Data
Privacy
Business
Alignment
SCRUM
Agile
Near Environment
Elemente, die wir
beeinflussen können.
Inner Environment
Elemente, die wir
kontrollieren können.
End-2-End
Testing
Test
Automation
Tester
Skills
Marketing
Unser
Testing
Placeholder
Als Beispiel ein SAP Projekt
mit eigenem Test Team,
Prozessen und Tools.
Disruptive Projects
SAP
Einflussfaktoren
Page 70
71. Time
AmountofChange
The risk of strategic drift
Page 71
Incremental Change
Fortlaufend kleinere
Änderungen, um die
Organisation zielgerichtet in
Bewegung zu halten.
Strategic Change
Grössere strategische
Änderungen, um mit den
Veränderungen im
Unternehmen mitzuhalten.
Change
Sich dauernd verändernde
Anforderungen aus dem
Unternehmen und der
Umwelt.
AmountofChange
72. Detailliertes Wissen von SwissQ in:
Testing in Scrum & Agile (inkl. Übernahme von Test-Aktivitäten)
Exploratives Testing
Testing für „New and Social Media“ und Mobile Applications
Testwerkzeug-Strategie
Entschlankung der Testaktivitäten und –dokumente
Praxisbezogene Aus- und Weiterbildung
Strategische Ausrichtung und Optimierung Ihres Testings
Übernahme von Testprojekten und -mandaten
Page 72