SlideShare ist ein Scribd-Unternehmen logo
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
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
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
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
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
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
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
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
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]
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
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%
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
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
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?
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
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

Weitere ähnliche Inhalte

Was ist angesagt?

Der Agile Qualitätsbaukasten - PHP Unconference 2014
Der Agile Qualitätsbaukasten - PHP Unconference 2014Der Agile Qualitätsbaukasten - PHP Unconference 2014
Der Agile Qualitätsbaukasten - PHP Unconference 2014
WebcsonsultsEU
 
Ich will agil testen! was muss ich können iqnite 2014 - verison 2.0
Ich will agil testen! was muss ich können   iqnite 2014 - verison 2.0Ich will agil testen! was muss ich können   iqnite 2014 - verison 2.0
Ich will agil testen! was muss ich können iqnite 2014 - verison 2.0
Michael Fischlein
 
Scrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADEDScrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADED
SwissQ Consulting AG
 
SE2013 ANECON Testen in agilen Projekten
SE2013 ANECON Testen in agilen ProjektenSE2013 ANECON Testen in agilen Projekten
SE2013 ANECON Testen in agilen Projekten
Peter Haberl
 
Realisierung von Prozessanwendungen auf Basis von Jakarta EE
Realisierung von Prozessanwendungen auf Basis von Jakarta EERealisierung von Prozessanwendungen auf Basis von Jakarta EE
Realisierung von Prozessanwendungen auf Basis von Jakarta EE
gedoplan
 
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
René Spengler
 
Mit agilen Prinzipien große Integrationstests einfach managen
Mit agilen Prinzipien große Integrationstests einfach managenMit agilen Prinzipien große Integrationstests einfach managen
Mit agilen Prinzipien große Integrationstests einfach managen
Christoph Schmiedinger
 
Abenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-WartungAbenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-Wartung
Ernest Wallmueller
 
PTA Presentation SpiraTeam in Action Case Study
PTA Presentation SpiraTeam in Action Case StudyPTA Presentation SpiraTeam in Action Case Study
PTA Presentation SpiraTeam in Action Case Study
Adam Sandman
 
Ein Dialog unter Fremden: Testautomatisierung in der Praxis
Ein Dialog unter Fremden: Testautomatisierung in der PraxisEin Dialog unter Fremden: Testautomatisierung in der Praxis
Ein Dialog unter Fremden: Testautomatisierung in der Praxis
Nico Orschel
 
Mehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements EngineeringMehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements Engineering
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Interaction & Information Design: Herausforderung für das Testen in agilen Pr...
Interaction & Information Design: Herausforderung für das Testen in agilen Pr...Interaction & Information Design: Herausforderung für das Testen in agilen Pr...
Interaction & Information Design: Herausforderung für das Testen in agilen Pr...
ONE Schweiz
 
Whitebox testing-phpughh
Whitebox testing-phpughhWhitebox testing-phpughh
Whitebox testing-phpughh
WebcsonsultsEU
 
Whitepaper QF-Test: GUI Testautomatisierung macht Spaß
Whitepaper QF-Test: GUI Testautomatisierung macht SpaßWhitepaper QF-Test: GUI Testautomatisierung macht Spaß
Whitepaper QF-Test: GUI Testautomatisierung macht Spaß
Claudia Baur
 
Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Referat: Scrum Rocks – Testing Sucks?! (reloaded)Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Digicomp Academy AG
 
Usability-Testing - nichts leichter als das!
Usability-Testing - nichts leichter als das!Usability-Testing - nichts leichter als das!
Usability-Testing - nichts leichter als das!
Namics – A Merkle Company
 

Was ist angesagt? (17)

Der Agile Qualitätsbaukasten - PHP Unconference 2014
Der Agile Qualitätsbaukasten - PHP Unconference 2014Der Agile Qualitätsbaukasten - PHP Unconference 2014
Der Agile Qualitätsbaukasten - PHP Unconference 2014
 
Ich will agil testen! was muss ich können iqnite 2014 - verison 2.0
Ich will agil testen! was muss ich können   iqnite 2014 - verison 2.0Ich will agil testen! was muss ich können   iqnite 2014 - verison 2.0
Ich will agil testen! was muss ich können iqnite 2014 - verison 2.0
 
Scrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADEDScrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADED
 
DA praesentation
DA praesentationDA praesentation
DA praesentation
 
SE2013 ANECON Testen in agilen Projekten
SE2013 ANECON Testen in agilen ProjektenSE2013 ANECON Testen in agilen Projekten
SE2013 ANECON Testen in agilen Projekten
 
Realisierung von Prozessanwendungen auf Basis von Jakarta EE
Realisierung von Prozessanwendungen auf Basis von Jakarta EERealisierung von Prozessanwendungen auf Basis von Jakarta EE
Realisierung von Prozessanwendungen auf Basis von Jakarta EE
 
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
 
Mit agilen Prinzipien große Integrationstests einfach managen
Mit agilen Prinzipien große Integrationstests einfach managenMit agilen Prinzipien große Integrationstests einfach managen
Mit agilen Prinzipien große Integrationstests einfach managen
 
Abenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-WartungAbenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-Wartung
 
PTA Presentation SpiraTeam in Action Case Study
PTA Presentation SpiraTeam in Action Case StudyPTA Presentation SpiraTeam in Action Case Study
PTA Presentation SpiraTeam in Action Case Study
 
Ein Dialog unter Fremden: Testautomatisierung in der Praxis
Ein Dialog unter Fremden: Testautomatisierung in der PraxisEin Dialog unter Fremden: Testautomatisierung in der Praxis
Ein Dialog unter Fremden: Testautomatisierung in der Praxis
 
Mehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements EngineeringMehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements Engineering
 
Interaction & Information Design: Herausforderung für das Testen in agilen Pr...
Interaction & Information Design: Herausforderung für das Testen in agilen Pr...Interaction & Information Design: Herausforderung für das Testen in agilen Pr...
Interaction & Information Design: Herausforderung für das Testen in agilen Pr...
 
Whitebox testing-phpughh
Whitebox testing-phpughhWhitebox testing-phpughh
Whitebox testing-phpughh
 
Whitepaper QF-Test: GUI Testautomatisierung macht Spaß
Whitepaper QF-Test: GUI Testautomatisierung macht SpaßWhitepaper QF-Test: GUI Testautomatisierung macht Spaß
Whitepaper QF-Test: GUI Testautomatisierung macht Spaß
 
Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Referat: Scrum Rocks – Testing Sucks?! (reloaded)Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Referat: Scrum Rocks – Testing Sucks?! (reloaded)
 
Usability-Testing - nichts leichter als das!
Usability-Testing - nichts leichter als das!Usability-Testing - nichts leichter als das!
Usability-Testing - nichts leichter als das!
 

Ähnlich wie Test-Alternativen

Die nächste Generation des Unit Testing
Die nächste Generation des Unit TestingDie nächste Generation des Unit Testing
Die nächste Generation des Unit Testing
Daniel Lehner
 
Next Level Unit Testing
Next Level Unit TestingNext Level Unit Testing
Next Level Unit Testing
Daniel Lehner
 
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Markus Unterauer
 
Einführung in die Software-Qualitätssicherung
Einführung in die Software-QualitätssicherungEinführung in die Software-Qualitätssicherung
Einführung in die Software-QualitätssicherungChristian Baranowski
 
Traceability von Software Anforderungen
Traceability von Software AnforderungenTraceability von Software Anforderungen
Traceability von Software Anforderungen
Markus Unterauer
 
Mehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements EngineeringMehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements Engineering
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Universität Zürich - erfolgreiches Testing
Universität Zürich - erfolgreiches TestingUniversität Zürich - erfolgreiches Testing
Universität Zürich - erfolgreiches TestingIBM Switzerland
 
UI Testautomation in der Praxis: Von Lokalisierung bis Nachhaltigkeit
UI Testautomation in der Praxis: Von Lokalisierung bis NachhaltigkeitUI Testautomation in der Praxis: Von Lokalisierung bis Nachhaltigkeit
UI Testautomation in der Praxis: Von Lokalisierung bis Nachhaltigkeit
Nico Orschel
 
Testgetriebene Softwareentwicklung
Testgetriebene SoftwareentwicklungTestgetriebene Softwareentwicklung
Testgetriebene Softwareentwicklung
jlink
 
Testmanagement mit Visual Studio 2013
Testmanagement mit Visual Studio 2013Testmanagement mit Visual Studio 2013
Testmanagement mit Visual Studio 2013
Nico Orschel
 
Automatisierte GUI-Tests mit Selenium
Automatisierte GUI-Tests mit SeleniumAutomatisierte GUI-Tests mit Selenium
Automatisierte GUI-Tests mit SeleniumBenjamin Schmid
 
Mehr Softwarequalität: Team Clean Coding
Mehr Softwarequalität: Team Clean CodingMehr Softwarequalität: Team Clean Coding
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop AnalyticsWindows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
Fabian Niesen
 
Mehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements EngineeringMehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements Engineering
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Testmanagement mit Visual Studio 2013 / CodedUI / Neues aus der Produktgruppe...
Testmanagement mit Visual Studio 2013 / CodedUI / Neues aus der Produktgruppe...Testmanagement mit Visual Studio 2013 / CodedUI / Neues aus der Produktgruppe...
Testmanagement mit Visual Studio 2013 / CodedUI / Neues aus der Produktgruppe...
Nico Orschel
 
Agiles Testen - Überblick
Agiles Testen - ÜberblickAgiles Testen - Überblick
Agiles Testen - Überblick
Claudia Haußmann 🦋
 
Mehr Softwarequalität: Team-Cleancoding
Mehr Softwarequalität: Team-CleancodingMehr Softwarequalität: Team-Cleancoding
Erfolgsfaktoren für modellbasiertes Testen
Erfolgsfaktoren für modellbasiertes TestenErfolgsfaktoren für modellbasiertes Testen
Erfolgsfaktoren für modellbasiertes Testen
trossner
 
Beyond Agile - when Freedom grows to Quality and Speed
Beyond Agile - when Freedom grows to Quality and SpeedBeyond Agile - when Freedom grows to Quality and Speed
Beyond Agile - when Freedom grows to Quality and Speed
Sebastian Bernt
 
DWX 2014 - Coded UI in der Praxis: Von Lokalisierung bis Nachhaltigkeit
DWX 2014 -  Coded UI in der Praxis: Von Lokalisierung bis NachhaltigkeitDWX 2014 -  Coded UI in der Praxis: Von Lokalisierung bis Nachhaltigkeit
DWX 2014 - Coded UI in der Praxis: Von Lokalisierung bis Nachhaltigkeit
Nico Orschel
 

Ähnlich wie Test-Alternativen (20)

Die nächste Generation des Unit Testing
Die nächste Generation des Unit TestingDie nächste Generation des Unit Testing
Die nächste Generation des Unit Testing
 
Next Level Unit Testing
Next Level Unit TestingNext Level Unit Testing
Next Level Unit Testing
 
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
 
Einführung in die Software-Qualitätssicherung
Einführung in die Software-QualitätssicherungEinführung in die Software-Qualitätssicherung
Einführung in die Software-Qualitätssicherung
 
Traceability von Software Anforderungen
Traceability von Software AnforderungenTraceability von Software Anforderungen
Traceability von Software Anforderungen
 
Mehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements EngineeringMehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements Engineering
 
Universität Zürich - erfolgreiches Testing
Universität Zürich - erfolgreiches TestingUniversität Zürich - erfolgreiches Testing
Universität Zürich - erfolgreiches Testing
 
UI Testautomation in der Praxis: Von Lokalisierung bis Nachhaltigkeit
UI Testautomation in der Praxis: Von Lokalisierung bis NachhaltigkeitUI Testautomation in der Praxis: Von Lokalisierung bis Nachhaltigkeit
UI Testautomation in der Praxis: Von Lokalisierung bis Nachhaltigkeit
 
Testgetriebene Softwareentwicklung
Testgetriebene SoftwareentwicklungTestgetriebene Softwareentwicklung
Testgetriebene Softwareentwicklung
 
Testmanagement mit Visual Studio 2013
Testmanagement mit Visual Studio 2013Testmanagement mit Visual Studio 2013
Testmanagement mit Visual Studio 2013
 
Automatisierte GUI-Tests mit Selenium
Automatisierte GUI-Tests mit SeleniumAutomatisierte GUI-Tests mit Selenium
Automatisierte GUI-Tests mit Selenium
 
Mehr Softwarequalität: Team Clean Coding
Mehr Softwarequalität: Team Clean CodingMehr Softwarequalität: Team Clean Coding
Mehr Softwarequalität: Team Clean Coding
 
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop AnalyticsWindows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
 
Mehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements EngineeringMehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements Engineering
 
Testmanagement mit Visual Studio 2013 / CodedUI / Neues aus der Produktgruppe...
Testmanagement mit Visual Studio 2013 / CodedUI / Neues aus der Produktgruppe...Testmanagement mit Visual Studio 2013 / CodedUI / Neues aus der Produktgruppe...
Testmanagement mit Visual Studio 2013 / CodedUI / Neues aus der Produktgruppe...
 
Agiles Testen - Überblick
Agiles Testen - ÜberblickAgiles Testen - Überblick
Agiles Testen - Überblick
 
Mehr Softwarequalität: Team-Cleancoding
Mehr Softwarequalität: Team-CleancodingMehr Softwarequalität: Team-Cleancoding
Mehr Softwarequalität: Team-Cleancoding
 
Erfolgsfaktoren für modellbasiertes Testen
Erfolgsfaktoren für modellbasiertes TestenErfolgsfaktoren für modellbasiertes Testen
Erfolgsfaktoren für modellbasiertes Testen
 
Beyond Agile - when Freedom grows to Quality and Speed
Beyond Agile - when Freedom grows to Quality and SpeedBeyond Agile - when Freedom grows to Quality and Speed
Beyond Agile - when Freedom grows to Quality and Speed
 
DWX 2014 - Coded UI in der Praxis: Von Lokalisierung bis Nachhaltigkeit
DWX 2014 -  Coded UI in der Praxis: Von Lokalisierung bis NachhaltigkeitDWX 2014 -  Coded UI in der Praxis: Von Lokalisierung bis Nachhaltigkeit
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
  • 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

Hinweis der Redaktion

  1. [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
  2. [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
  3. Weitere Infos: Assertion Coverage – Mutation Testing - https://www.slideshare.net/SebastianDietrich/mutationtesting-mit-pit
  4. 6
  5. 7
  6. Weitere Infos: Testaufwand @ Wikipedia: https://de.wikipedia.org/wiki/Testaufwand
  7. 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
  8. 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.
  9. Weitere Infos: Review @ Wikipedia: https://de.wikipedia.org/wiki/Review_(Softwaretest)
  10. 13
  11. Weitere Infos: TDD @ Wikipedia: https://de.wikipedia.org/wiki/Testgetriebene_Entwicklung
  12. Weitere Infos: BDD @ Wikipedia: https://de.wikipedia.org/wiki/Behavior_Driven_Development
  13. Weitere Kontaktmöglichkeiten: Sebastian.Dietrich@e-movimento.com Skype: sebastian_dietrich http://de.wikipedia.org/wiki/Benutzer:Sebastian.Dietrich