SwissQ Event vom 14. Juni 2011

1. SwissQ Testing Trends &
Benchmarking 2011
Autor: SwissQ
At the
of Software Testing
SwissQ Event – 14. Juni 2011

2. Ziel des Abends / Veranstaltung
Page 2

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

4. Heutiges „Line-Up“
Page 4
Silvio Moser
CTO SwissQ
Marcel Rütschi
Head Academy
Adrian Stoll
Scrum & Testing Geek

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

7. Was ändert sich in unserer Welt?
Page 7

8. Was ändert sich in unserer Welt?
Page 8
 Community Plattform
für Migros-Kunden
 Produktebewertungen
& Kommentare
 Umfragen &
Kampagnen

9. Was ändert sich in unserer Welt?
Page 9
 Coupons & Aktionen
 Mobile Payment
 iPhone & Android App
 diverse Schnittstellen

10. BASIS DES REPORTS
Page 10

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

12. Erhebungsgrundlagen – Wirtschafts-Sektoren
Page 12

13. Erhebungsgrundlagen – IT-Mitarbeitende
Page 13

14. Erhebungsgrundlagen – Aufgabenbereich
Page 14

15. WO STEHEN WIR?
Page 15

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.

17. Ausgangslage in den Projekten
Page 17

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

23. Testaufwand
Page 23

24. Wer führt Tests durch
Page 24

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

32. Scrum Testing im Detail
ST/AT ST/AT ST/AT
S3 S4 S5
Scrum
ST/AT ST/AT
S3 S4 S5
ST/AT
Embedded
Page 32

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

39. Techniken und Technologien
Grosser Anteil von Explorativem Testen
Page 39

40. Techniken und Technologien
Traditionelle Test-Techniken ja – unbedingt! – aber "Light"
Page 40

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

51. Investitionen
Page 51

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

57. Aus- und Weiterbildung
Wissen, das Kapital einer Unternehmung

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

61. SwissQ Weiterbildungs-Angebot
Page 61
Test Basiswissen
Zertifizierung
Test Management
Test Engineering
Test Tools
Angrenzende Themen
Theorie Praxis

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

63. Stakeholder-Analyse?
Tester
Test Team
Test Manager
Entwickler
Lieferanten Benutzer /
Kunde
ProjektleiterReq-Engineer‘s
Page 63

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

66. Kostenplanung
0
10
20
30
40
50
60
70
80
Jan Feb Mär Apr Mai Jun Jul Aug Sep Okt Nov Dez
Plankosten
vs.
Ist-­‐Kosten
in
TCHF
Plankosten Ist-Kosten

67. WOHIN GEHT ES?
Page 67

68. Swiss Testing Trends 2011
Page 68

69. Fazit
Schneller – Flexibler - Agiler
Page 69

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

73. Inhouse Präsentation
Page  73

74. Besten Dank für Ihre
Aufmerksamkeit!
Fragen?
Page 74

75. FEEDBACK?
Page 75

76. Kontaktieren Sie uns unter
Page 76
1
2
3
4
5
6
7
8
 SwissQ Consulting AG
Stadthaus-Quai 15
8001 Zürich
 Tel. +41 (0)43 288 88 40
 Fax +41 (0)43 288 88 39
 www.SwissQ.it
 info@swissq.it
Koordinaten