DWX 2014 - Coded UI in der Praxis: Von Lokalisierung bis Nachhaltigkeit
Test-Alternativen
1. e-movimento Software Design & Beratung GmbH
1030 Wien ● Marxergasse 7/26 ► www.e-movimento.com
Effizientere und effektivere
Alternativen zum Testen
DI Sebastian Dietrich
Sebastian.Dietrich@e-movimento.com
2. Testen
Warum testen wir?
Warum testen wir?
Warum schreiben wir Unit-Test?
Warum schreiben wir
Integrationstests?
Warum schreiben wir Testfälle?
Warum führen wir Testfälle durch?
Um Kosten zu reduzieren
Entwicklungskosten, Wartungskosten
Fehlerbehebungskosten
Imagekosten
…
Wieviel darf uns daher der Test
kosten?
Performancetests
Securitytests
Penetrationtests
Integrationstests
Systemtests
Loadtests
Abnahmetests
Usablity Test
Unit-Tests
Lasttests
Regressiontests
Fehlertests
Schnittstellentests
Installationstests
Crashtests
Smoketests
Stresstests
► www.e-movimento.com, Sebastian Dietrich2
3. Systemtest
Kosten – Nutzen Rechnung
Kosten Nutzen
Systemtestaufwand:
~ 1 PT / Testfall
Systemtest findet
~ 1 Fehler / Testfall
Fehlerbehebungsaufwand:
~ 1PT / Fehler
(10x wie während Entwicklung)
Je behobener Fehler:
0,5 – 0,8 neue (unentdeckte)
Fehler
80 – 150%
der Entwicklungskosten
Systemtest findet
max. 25 – 55% der Fehler
Systemtest:
Teststufe, bei der das gesamte System
gegen die gesamten Anforderungen getestet wird.
[Jones 86], [Jones 96a], [Jones 96b], [Shull 02], [McConnell 04]
► www.e-movimento.com, Sebastian Dietrich3
4. Unittest
Kosten – Nutzen Rechnung
Kosten Nutzen
Unit-Testaufwand:
~ 2-3x Entwicklungsaufwand
„Code Coverage“ ?
„Refactoring“ ?
Fehlerbehebungsaufwand:
~ 1h / Fehler
(1/10 wie während Test)
Je behobener Fehler:
0,5 – 0,8 neue (unentdeckte)
Fehler
~ 50% der Entwicklungskosten Unit-Test findet
max. 15 – 70% der Fehler
Unit-Tests:
Teststufe, bei der funktionale Einzelteile (Module)
auf korrekte Funktionalität geprüft werden.
[Jones 01], [Humphrey 89], [Software Metrics 01]
► www.e-movimento.com, Sebastian Dietrich4
5. Unittests
Warum gute Unittests so teuer sind
Gute Unittests (gilt auch für TDD):
Haben Assertions (die den Vertrag der Methoden testen):
Vorbedingungen (typische / untypische / extreme / unerlaubte)
Nachbedingungen (Rückgabewerte & Exceptions, State-Änderungen)
Invarianten (was sich nicht ändern darf)
Haben 100% Assertion-Coverage (Code-Coverage ist unwichtig)
Testen Units (& mocken Referenzen auf andere Units weg)
Berücksichtigen State (Quasimodale & Modale Klassen) und
Reihenfolge der Methodenaufrufe (Unimodale & Modale Klassen)
Hinterlassen das System, wie sie es vorgefunden haben
Laufen daher in beliebiger Reihenfolge
Sind Refactoring-Safe
Testen auch das Design (z.B. Liskovsches Substitutionsprinzip)
Laufen auf dem CI Server & geben rasches Feedback (< 1 min.)
► www.e-movimento.com, Sebastian Dietrich5
6. Testen
Fazit und Alternativen
Fazit:
Testen ist sehr aufwändig (lt. Literatur 15%-70% Gesamtaufwand)
Testen findet bei weitem nicht alle Fehler (max. 80%)
Wir benötigen Test-Ende Kriterien und Alternativen
Alternativen:
Exploratives Testen
Code-Reviews
Test-Driven Development
Behavior-Driven Development
► www.e-movimento.com, Sebastian Dietrich8
finden / verhindern
mehr Bugs pro
Zeiteinheit als Testen
7. Testen
Test-Ende Kriterien
Test-Ende Kriterien:
Wenn Anzahl der zu findenden Fehler gefunden wurden…
𝐾𝑆𝐿𝑂𝐶𝑡𝑒𝑠𝑡𝑒𝑑 × 2 + 𝐾𝑆𝐿𝑂𝐶¬𝑡𝑒𝑠𝑡𝑒𝑑 × 20
< 𝐵𝑢𝑔𝑠 𝑒𝑥𝑝 <
𝐾𝑆𝐿𝑂𝐶𝑡𝑒𝑠𝑡𝑒𝑑 × 10 + 𝐾𝑆𝐿𝑂𝐶¬𝑡𝑒𝑠𝑡𝑒𝑑 × 50
Wenn Kosten für Test > Kosten von Fehlern in Produktion…
► www.e-movimento.com, Sebastian Dietrich9
9. Test Alternativen
Exploratives Testen vs. klassischer Test
Gleiche Fehlererkennungsrate
gleiche Effektivität
Weniger Vorbereitung
höhere Effizienz
Bugs schneller gefunden
schnelleres Feedback
Weniger False-Positives
► www.e-movimento.com, Sebastian Dietrich11
Testen
Test
Design
Lernen
[Itkonen, Mäntylä 13]
10. Code-Reviews
Kosten – Nutzen Rechnung
Kosten Nutzen
Reviewaufwand:
~ 1 PT / Modul (~100 Klassen)
Reviews finden: technische Fehler
2-4x schneller Bugs als Tests
Fehlerbehebungsaufwand:
wenige Minuten bis Monate
(Architekturfehler)
Weitere Fehler werden sichtbar
Verbreitetes Wissen, Weiterbildung
Lesbarkeit = Wartbarkeit
10% (kontinuierlich) - 105%
(nachträglich) des
Entwicklungsaufwand
Reviews finden 20-90% der Fehler
(je Review-Art)
Code-Reviews:
Statische Testmethode, bei der Code und
Architektur (manuell) geprüft werden.
[Jones 02], [Fagan 76], [Brown 99], [Russel 91]
► www.e-movimento.com, Sebastian Dietrich12
11. Test Alternativen
Code Reviews
Bessere technische Qualität
(automatische) Reviews &
Qualitätsverbesserungen
Weniger Fehler
(nach Entwicklung)
Bessere technische Qualität
Mehr
Entwicklungsaufwand
Weniger Gesamtkosten
Höhere Produktivität
(während Entwicklung)
Weniger Wartungsaufwand
Weniger Testaufwand
Weniger Fehler-
behebungsaufwand
ca.10% 18%-81%
10%-105%
50%-170%
min. 20%
11%-73%
► www.e-movimento.com, Sebastian Dietrich13
min. 10%
20%
-
90%
12. Test-Driven Development
Kosten – Nutzen Rechnung
Testmethode, bei der der Entwickler konsequent Modultests
entwickelt bevor er die Module entwickelt.
Kein Codieren, „nur“ Tests fixen!
[George & Williams 03]
► www.e-movimento.com, Sebastian Dietrich14
Kosten Nutzen
TDD-Aufwand:
+ 16% Entwicklungsaufwand
18% weniger Bugs als wenn Tests
nach Code
Fehlerbehebungsaufwand:
keiner – Codieren = Fehler fixen
2 Hüte Besseres Design
Testbarer Code = Besseres Design
TDD findet
max. 33 – 88% der Fehler
13. Test Alternativen
Behavior-Driven Development (BDD)
Typische Probleme beim Testen (bei denen BDD hilft):
TDD weiss nicht wo man anfangen kann
Zuerst Features automatisieren (Tests brechen),
dann mittels TDD Features umsetzen
Spezifikation ist ungenau / mehrdeutig / veraltet
eindeutigere, testbare Spezifikationen
Features brechen, wenn veraltet
Dinge, die bereits funktionierten, funktionieren nicht mehr
Abdeckung aller Features mit Tests Fail Fast
GUI- und Schnittstellen ändern sich laufend hoher
Wartungsaufwand für GUI- und Schnittstellentests
BDD zunächst auf Serviceebene, dann auf Page Objects
► www.e-movimento.com, Sebastian Dietrich15
14. Test Alternativen
Was ist die beste Alternative?
► www.e-movimento.com, Sebastian Dietrich16
Was aber verhindert Bugs am effektivsten?
(... und ist nebenbei wichtigster Faktor für den Projekterfolg?)
50% aller Bugs?
60% aller Bugs?
70% aller Bugs?
80% aller Bugs?
90% aller Bugs?
15. Test Alternativen
Was ist die beste Alternative?
Weniger Features, weniger Code, weniger Bugs
Standish Group Chaos Report 2013: „deliver less for less“
Nur 20% der Features werden oft verwendet, 50% nie / fast nie
Es gibt keinen Grund für große Projekte, große Projekte
können auf 10% ihrer Größe reduziert werden
Jedes große IT Projekt kann in eine Reihe kleinerer Projekte
aufgeteilt werden
Wie?
Analysiere nicht was sich der Fachbereich oder Endanwender...
... wünscht oder behauptet zu brauchen.
Analysiere die Probleme der Endanwender
Setze nie 100% der Anforderungen um, setze keine Anforderung
100% um - sondern nur die (Teile) mit höchstem Wert
► www.e-movimento.com, Sebastian Dietrich17
16. Vielen Dank für Ihre Aufmerksamkeit!
Q&A[Sebastian Dietrich]
Sebastian.Dietrich@e-movimento.com
http://managing-java.blogspot.com
► www.e-movimento.com, Sebastian Dietrich18
Hinweis der Redaktion
[Jones 1996] Applied Software Measurement, Capers Jones, 1996
[Jones 1986] Programming Productivity, Capers Jones, 1986
[Jones 1996] Software Defect-Removal Efficiency, Capers Jones, 1996
[Shull 2002] What We Have Learned About Fighting Defects, Shull et al 2002
[McConnell 2004] Code Complete, Steve McConnell 2004
[Software Metrics 01] http://www.softwaremetrics.com/Articles/defects.htm
[Jones 01] , Capers Jones, 2001
[Humphrey 89] Managing the software process, Watts S. Humphrey, 1989
[Software Metrics 01] http://www.softwaremetrics.com/Articles/defects.htm
Weitere Infos:
Assertion Coverage – Mutation Testing - https://www.slideshare.net/SebastianDietrich/mutationtesting-mit-pit
6
7
Weitere Infos:
Testaufwand @ Wikipedia: https://de.wikipedia.org/wiki/Testaufwand
Literatur:
Steve McConnell: Code Complete A Practical Handbook of Software Construction. 2. Auflage. Microsoft Press, 2004, ISBN 978-0-7356-1967-8
Carnegie Mellon University's CyLab Sustainable Computing Consortium
Weitere Infos:
Exploratives Testen @ Wikipedia: https://en.wikipedia.org/wiki/Exploratory_testing
Itkonen, Juha; Mäntylä, Mika V. (2013-07-11). "Are test cases needed? Replicated comparison between exploratory and test-case-based software testing". Empirical Software Engineering. 19 (2): 303–342.
Weitere Infos:
Review @ Wikipedia: https://de.wikipedia.org/wiki/Review_(Softwaretest)
13
Weitere Infos:
TDD @ Wikipedia: https://de.wikipedia.org/wiki/Testgetriebene_Entwicklung
Weitere Infos:
BDD @ Wikipedia: https://de.wikipedia.org/wiki/Behavior_Driven_Development
Weitere Kontaktmöglichkeiten:
Sebastian.Dietrich@e-movimento.com
Skype: sebastian_dietrich
http://de.wikipedia.org/wiki/Benutzer:Sebastian.Dietrich