Was ist effizienter und effektiver als Tests (im Finden von Fehlern)

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

8. Testen
Test-Ende Kriterien?
 Test-Ende Kriterien:
 Wenn Fehlerdichte genügend ist…
(Kommerzielle Software ~15 – 50, Microsoft-Anwendungen ~0,5)
 Wenn Aufwand pro gefundenem Fehler zu hoch wird…
Fehlerdichte Klassifizierung
< 0,5 stabile Programme
0,5 … 3 reifende Programme
3 … 6 labile Programme
6 … 10 fehleranfällige Programme
> 10 unbrauchbare Programme
20 – 50 ungetestete Programme
Schadenersatz
potentiell
Schadenersatz
# Bugs
► www.e-movimento.com, Sebastian Dietrich10

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