Das Dokument behandelt die Bedeutung und Kosten des Testens in der Softwareentwicklung, einschließlich Unit-Tests, Integrationstests und Systemtests. Es wird darauf hingewiesen, dass Tests zwar dazu beitragen, Fehler zu identifizieren, aber oft nicht alle Fehler entdeckt werden und der Testaufwand erhebliche Ressourcen erforderlich macht. Alternatives Testen wie exploratives Testen und Code-Reviews werden als effiziente Methoden zur Fehlervermeidung hervorgehoben, um die Softwarequalität zu verbessern.

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