SlideShare uma empresa Scribd logo
1 de 38
© Zühlke 2012
Matthias Kraaz
Wirtschaftlich
Software
testen
Matthias Kraaz
6. Dezember 2012
• Soll alle Fehler finden
• Testzyklen in Nullzeit
• Verifikation klappt auf Anhieb
• Knappe Zeit
• Knappes Budget
• Häufige Änderungen
Die Schmerzen des Test-Managers
© Zühlke 2012
Testautomatisierung
Design for Testability
Automatisierte Verifizierungstests
Teststufen
Testherleitungsverfahren und die Gießkanne
Statische Analyse
Reviews
Agenda
6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
Elektronik
Software
Point of Control
Point of Observation
Elektronik
Software
Point of Observation
Point of Control
Elektronik
Software
Point of Observation
Point of Control
Elektronik
Software
Point of Observation
Point of Control
Elektronik
Software
Point of Observation
Point of Control
Elektronik
Software
Point of Observation
Point of Control
Design for Testability
© Zühlke 2012
Liefern Sie aus, was Sie getestet haben:
• Finale Version sollte debugbar und testbar sein
• Test-Schnittstellen versperren, aber drin lassen
– Sonderfall Wartungstests / STK / MTK
– Sonderfall Produktionstests
Tricks, damit die Herstellkosten nicht steigen:
• optionale Bestückung
• modulare Bauweise
• …
Design for Testability
6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
Testling Signal-Adaption Zum Test-System 
© Zühlke 2012
• Fehler werden früher gefunden
• Testfallexplosion besser im Griff
– Vielzahl von Eingangs-/Ausgangsparametern automatisiert testbar
• Es gibt öfter einen aktuellen Testbericht
• Regressionstests ermöglichen Refactoring
• Stresstests, lange Testläufe möglich
• Gibt Sicherheit und Vertrauen
• Bessere Dokumentation / Nachvollziehbarkeit der Tests
– Regularien-freundlich!
Testautomatisierung
Vorteile
6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
© Zühlke 2012
• Erstellung von Tests aufwendiger,
Produktivität des Testteams sinkt anfänglich
• Pflege von Tests aufwendiger
• Die meisten Fehler werden während der Testerstellung gefunden
• Tests haben reduzierte Variabilität
• Tests verifizieren nur, was hineinprogrammiert wurde
 Mit manuellen / explorativen Tests kombinieren
Testautomatisierung
Hinweise
6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
© Zühlke 2012
• Testling sollte gewisse Stabilität erreicht haben
• Mindestens zweiten Teststand vorsehen
• Zuverlässige Hardware verwenden
• KISS (Keep it small and simple)
Testautomatisierung
Hinweise
6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
© Zühlke 2012
• Alle Tests werden automatisiert
• Sofortige Kosteneinsparung durch Automatisierung
• Capture-Replay ohne Nacharbeit
• Ein zugekauftes Werkzeug, das perfekt passt
Testautomatisierung
Unrealistisch
6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
Unrealistisch!
© Zühlke 2012
Eingangsdaten für Berechnung:
• Kosten für manuelle Tests
– Erstellung der Testfallspezifikationen
– Manuelle Testdurchführung
• Kosten für automatisierte Tests
– Erstellung der Testskripte
– Pflege der Testskripte
– Automatisierte Testdurchführung
– Infrastruktur
• Parameter
– Anzahl manueller(!) Testläufe
– Kosten pro Personentag
– Anteil nicht automatisierter Tests
ROI von Testautomatisierung
Praxisbeispiel
Wirtschaftlich Software testen | Matthias Kraaz 6. Dezember 2012
© Zühlke 2012
- €
200,000 €
400,000 €
600,000 €
800,000 €
1,000,000 €
1,200,000 €
1,400,000 €
1 2 3 4
Kosten nach Jahren
Mit Automatisierung Rein manuell
ROI von Testautomatisierung
Praxisbeispiel
Wirtschaftlich Software testen | Matthias Kraaz 6. Dezember 2012
© Zühlke 2012
Man nehme:
• Kodierende Tester / testende Entwickler
• Unit Test Framework
• Mock Generator
• Build & Deploy & Run automatisieren
Was macht es schwierig:
• Abhängigkeiten
• Design der Schnittstellen
Automatisierung von Komponententests
6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
Test
Driver
Component
under Test
Mock
© Zühlke 2012
• Eventuell mehrere Integrationsstufen
• Herausforderungen je nach Anteil Software / Elektronik
Automatisierung von Integrationstests
6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
Automatisierte Verifizierungstests
© Zühlke 2012
Verifizierungstests laufen automatisiert während Entwicklung
• Vorschau auf Verifizierungsergebnis
• Ruhiger Schlaf
Automatisierte Verifizierungstests (IV&V)
• Zeitdruck, Kosten von Wiederholungen
• Test-Infrastruktur der Entwicklung kann wiederverwendet werden
• Validierung der Test-Infrastruktur
• „Test to verify“ statt „test to kill“
Automatisierte Verifizierungstests
Wirtschaftlich Software testen | Matthias Kraaz 6. Dezember 2012
© Zühlke 2012
• Fehlerkosten sinken
• Softwarequalität steigt
• Keine bösen Überraschungen
– in der Verifikation oder bei der Abnahme
• Testautomatisierung lohnt sich
– auch wenn der genaue ROI schwer zu berechnen ist
• Wir führen Projekte nur noch mit Testautomatisierung durch
– auf allen Test-Ebenen
– auch im nicht regulierten Umfeld
Testautomatisierung
Fazit
6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
© Zühlke 2012
Vorteile von Komponenten- und Integrationstests
• Weniger Aufwand pro Test
• Hohe Testtiefe bequem erreichbar
– Hohe Überdeckung von Parametern (Kombinationen, Äquivalenzklassen, Grenzwerte)
– Hohe Überdeckung von Zustandsmaschinen
– Robustheit-Tests
• Früher durchführbar
• Häufiger durchführbar
• Fehlerursache leichter zu lokalisieren
• Leichter automatisierbar
Teststufen
6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
© Zühlke 2012
Zu wenig Budget Nur Systemtests Optimiert
Budget-Verteilung und Testtiefe
Untere Teststufen
Systemtests
Testtiefe
Teststufen
Wirtschaftlich Software testen | Matthias Kraaz 6. Dezember 2012
© Zühlke 2012
Teststufen
Wirtschaftlich Software testen | Matthias Kraaz
Integrationstests
Komponententests
6. Dezember 2012
Systemtests
© Zühlke 2012
Nachteile von Komponenten- und Integrationstests
• Infrastruktur erforderlich
• Automatisierung fast unausweichlich
• Aussagekraft muss von oberer Teststufe überprüft werden
• Grundstock von Systemtests muss sein
Teststufen
Wirtschaftlich Software testen | Matthias Kraaz 6. Dezember 2012
© Zühlke 2012
Nicht mit der Gießkanne testen!
Fokus auf
• Sicherheitskritische …
• Wichtige …
• Komplexe …
• Neue …
• Durch Bugs aufgefallene …
• … Anforderungen
• … Software-Komponenten
6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
© Zühlke 2012
Nicht mit der Gießkanne testen!
Testherleitungsverfahren
• Spezifikationsorientiert
• Strukturorientiert
• Äquivalenzklassen plus Grenzwertanalyse
• Entscheidungstabellen
• Zustandsbasiert
• Anwendungsfallbasiert
• Erfahrungsbasiert
• …
6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
© Zühlke 2012
Statische Analyse einsetzen!
Statische
Analyse
Architektur Metriken
Code-
Checker
Stil
Kodier-
regeln
Laufzeit-
fehler
Sicherheits-
probleme
Reviews optimieren!
© Zühlke 2012
• Gießkanne weg, systematische Testherleitung
• Wenn Reviews Pflicht: Nutzen maximieren, auf Testbarkeit achten
• Wenn Teststufen vorhanden: Nutzen maximieren
• Design for Testability
– Voraussetzung für sinnvolle Teststufen
– Erleichterung der Automatisierung
– Software-Architektur in Zusammenarbeit von SA und TM
• Teststufen einführen
• Automatisierung von Systemtests
– Automatisierte Verifizierungstests
• Parallel: statische Analyse
Priorisierung
6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
© Zühlke 2012
Lektüre (1)
Wirtschaftlich Software testen | Matthias Kraaz
CCElizabeth/Table4Five
6. Dezember 2012
© Zühlke 2012
• Daniel Mölle:
Stabile Software durch Design for Testability
(iX 11/2012, SlideShare)
• Matthias Kraaz:
Wirtschaftlich Software testen
(Kongressband)
• Matthias Kraaz:
Wirtschaftlich testen
(MEDengineering 9-10/2012, SlideShare)
• Matthias Kraaz:
Qualitätssicherung in Compact Projekten
(dotNetPro 02/2012, SlideShare)
Lektüre (2)
Wirtschaftlich Software testen | Matthias Kraaz
CCElizabeth/Table4Five
6. Dezember 2012
© Zühlke 2012
• Zusammenarbeit Tester und Entwickler:
Design for Testability & Testautomatisierung
• Test-Budget optimal nutzen
• Im regulierten Umfeld:
Nutzen ziehen aus Dingen, die ich ehe machen muss
Zur Schmerzlinderung empfehle ich…
6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz

Mais conteúdo relacionado

Destaque

Software Systems as Cities
Software Systems as CitiesSoftware Systems as Cities
Software Systems as CitiesRichard Wettel
 
Visually Localizing Design Problems with Disharmony Maps
Visually Localizing Design Problems with Disharmony MapsVisually Localizing Design Problems with Disharmony Maps
Visually Localizing Design Problems with Disharmony MapsRichard Wettel
 
Software Systems as Cities: a Controlled Experiment
Software Systems as Cities: a Controlled ExperimentSoftware Systems as Cities: a Controlled Experiment
Software Systems as Cities: a Controlled ExperimentRichard Wettel
 
Writing User Stories (04/2012)
Writing User Stories (04/2012)Writing User Stories (04/2012)
Writing User Stories (04/2012)Mai Quay
 
Visual Exploration of Large-Scale System Evolution
Visual Exploration of Large-Scale System EvolutionVisual Exploration of Large-Scale System Evolution
Visual Exploration of Large-Scale System EvolutionRichard Wettel
 

Destaque (6)

Software Systems as Cities
Software Systems as CitiesSoftware Systems as Cities
Software Systems as Cities
 
Visually Localizing Design Problems with Disharmony Maps
Visually Localizing Design Problems with Disharmony MapsVisually Localizing Design Problems with Disharmony Maps
Visually Localizing Design Problems with Disharmony Maps
 
Langlebige architekturen
Langlebige architekturenLanglebige architekturen
Langlebige architekturen
 
Software Systems as Cities: a Controlled Experiment
Software Systems as Cities: a Controlled ExperimentSoftware Systems as Cities: a Controlled Experiment
Software Systems as Cities: a Controlled Experiment
 
Writing User Stories (04/2012)
Writing User Stories (04/2012)Writing User Stories (04/2012)
Writing User Stories (04/2012)
 
Visual Exploration of Large-Scale System Evolution
Visual Exploration of Large-Scale System EvolutionVisual Exploration of Large-Scale System Evolution
Visual Exploration of Large-Scale System Evolution
 

Semelhante a Wirtschaftlich Software testen (ESE-Kongress 2012)

Business Case für eine Toolchain-Integrationslösung
Business Case für eine Toolchain-IntegrationslösungBusiness Case für eine Toolchain-Integrationslösung
Business Case für eine Toolchain-IntegrationslösungPlanview
 
Dipl.-Ing. (FH) Wolfgang Fröhlich (Anecon)
Dipl.-Ing. (FH) Wolfgang Fröhlich (Anecon)Dipl.-Ing. (FH) Wolfgang Fröhlich (Anecon)
Dipl.-Ing. (FH) Wolfgang Fröhlich (Anecon)Praxistage
 
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.0Michael Fischlein
 
SAP IdM Wartungsende 2027... und was nun?
SAP IdM Wartungsende 2027... und was nun?SAP IdM Wartungsende 2027... und was nun?
SAP IdM Wartungsende 2027... und was nun?IBsolution GmbH
 
"Erfolgreiche Strategien zur Migration veralteter Software" Präsentation vom ...
"Erfolgreiche Strategien zur Migration veralteter Software" Präsentation vom ..."Erfolgreiche Strategien zur Migration veralteter Software" Präsentation vom ...
"Erfolgreiche Strategien zur Migration veralteter Software" Präsentation vom ...Bernhard Schimunek
 
Applikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die CloudApplikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die CloudAarno Aukia
 
Automatisiertes Testen von Software in C++ (mit dem Test Framework Google Test)
Automatisiertes Testen von Software in C++ (mit dem Test Framework Google Test)Automatisiertes Testen von Software in C++ (mit dem Test Framework Google Test)
Automatisiertes Testen von Software in C++ (mit dem Test Framework Google Test)Florian Wolters
 
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
 
Celonis Process Mining - wzk partner
Celonis Process Mining - wzk partnerCelonis Process Mining - wzk partner
Celonis Process Mining - wzk partnerHolger Kock
 
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 NachhaltigkeitNico Orschel
 
Individuelle Software Entwicklung
Individuelle Software EntwicklungIndividuelle Software Entwicklung
Individuelle Software EntwicklungDorie Fehlmann
 
Dv 20 sdlc_oss_automation
Dv 20 sdlc_oss_automationDv 20 sdlc_oss_automation
Dv 20 sdlc_oss_automationTorsten Glunde
 
Roadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht'sRoadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht'scamunda services GmbH
 
Scrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADEDScrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADEDSwissQ Consulting AG
 
Universität Zürich - erfolgreiches Testing
Universität Zürich - erfolgreiches TestingUniversität Zürich - erfolgreiches Testing
Universität Zürich - erfolgreiches TestingIBM Switzerland
 
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
 
Implementierung von R im Mittelstand
Implementierung von R im MittelstandImplementierung von R im Mittelstand
Implementierung von R im Mittelstandeoda GmbH
 

Semelhante a Wirtschaftlich Software testen (ESE-Kongress 2012) (20)

Business Case für eine Toolchain-Integrationslösung
Business Case für eine Toolchain-IntegrationslösungBusiness Case für eine Toolchain-Integrationslösung
Business Case für eine Toolchain-Integrationslösung
 
Dipl.-Ing. (FH) Wolfgang Fröhlich (Anecon)
Dipl.-Ing. (FH) Wolfgang Fröhlich (Anecon)Dipl.-Ing. (FH) Wolfgang Fröhlich (Anecon)
Dipl.-Ing. (FH) Wolfgang Fröhlich (Anecon)
 
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
 
Citrix Day 2014: APPDNA
Citrix Day 2014: APPDNACitrix Day 2014: APPDNA
Citrix Day 2014: APPDNA
 
SAP IdM Wartungsende 2027... und was nun?
SAP IdM Wartungsende 2027... und was nun?SAP IdM Wartungsende 2027... und was nun?
SAP IdM Wartungsende 2027... und was nun?
 
"Erfolgreiche Strategien zur Migration veralteter Software" Präsentation vom ...
"Erfolgreiche Strategien zur Migration veralteter Software" Präsentation vom ..."Erfolgreiche Strategien zur Migration veralteter Software" Präsentation vom ...
"Erfolgreiche Strategien zur Migration veralteter Software" Präsentation vom ...
 
Applikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die CloudApplikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die Cloud
 
Agile BI in der Praxis - Agiles Testen
Agile BI in der Praxis - Agiles TestenAgile BI in der Praxis - Agiles Testen
Agile BI in der Praxis - Agiles Testen
 
Automatisiertes Testen von Software in C++ (mit dem Test Framework Google Test)
Automatisiertes Testen von Software in C++ (mit dem Test Framework Google Test)Automatisiertes Testen von Software in C++ (mit dem Test Framework Google Test)
Automatisiertes Testen von Software in C++ (mit dem Test Framework Google Test)
 
Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Referat: Scrum Rocks – Testing Sucks?! (reloaded)Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Referat: Scrum Rocks – Testing Sucks?! (reloaded)
 
Android Testing
Android Testing Android Testing
Android Testing
 
Celonis Process Mining - wzk partner
Celonis Process Mining - wzk partnerCelonis Process Mining - wzk partner
Celonis Process Mining - wzk partner
 
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
 
Individuelle Software Entwicklung
Individuelle Software EntwicklungIndividuelle Software Entwicklung
Individuelle Software Entwicklung
 
Dv 20 sdlc_oss_automation
Dv 20 sdlc_oss_automationDv 20 sdlc_oss_automation
Dv 20 sdlc_oss_automation
 
Roadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht'sRoadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht's
 
Scrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADEDScrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADED
 
Universität Zürich - erfolgreiches Testing
Universität Zürich - erfolgreiches TestingUniversität Zürich - erfolgreiches Testing
Universität Zürich - erfolgreiches Testing
 
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
 
Implementierung von R im Mittelstand
Implementierung von R im MittelstandImplementierung von R im Mittelstand
Implementierung von R im Mittelstand
 

Wirtschaftlich Software testen (ESE-Kongress 2012)

  • 1. © Zühlke 2012 Matthias Kraaz Wirtschaftlich Software testen Matthias Kraaz 6. Dezember 2012
  • 2. • Soll alle Fehler finden • Testzyklen in Nullzeit • Verifikation klappt auf Anhieb • Knappe Zeit • Knappes Budget • Häufige Änderungen Die Schmerzen des Test-Managers
  • 3. © Zühlke 2012 Testautomatisierung Design for Testability Automatisierte Verifizierungstests Teststufen Testherleitungsverfahren und die Gießkanne Statische Analyse Reviews Agenda 6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
  • 11. © Zühlke 2012 Liefern Sie aus, was Sie getestet haben: • Finale Version sollte debugbar und testbar sein • Test-Schnittstellen versperren, aber drin lassen – Sonderfall Wartungstests / STK / MTK – Sonderfall Produktionstests Tricks, damit die Herstellkosten nicht steigen: • optionale Bestückung • modulare Bauweise • … Design for Testability 6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
  • 12. Testling Signal-Adaption Zum Test-System 
  • 13.
  • 14.
  • 15.
  • 16. © Zühlke 2012 • Fehler werden früher gefunden • Testfallexplosion besser im Griff – Vielzahl von Eingangs-/Ausgangsparametern automatisiert testbar • Es gibt öfter einen aktuellen Testbericht • Regressionstests ermöglichen Refactoring • Stresstests, lange Testläufe möglich • Gibt Sicherheit und Vertrauen • Bessere Dokumentation / Nachvollziehbarkeit der Tests – Regularien-freundlich! Testautomatisierung Vorteile 6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
  • 17. © Zühlke 2012 • Erstellung von Tests aufwendiger, Produktivität des Testteams sinkt anfänglich • Pflege von Tests aufwendiger • Die meisten Fehler werden während der Testerstellung gefunden • Tests haben reduzierte Variabilität • Tests verifizieren nur, was hineinprogrammiert wurde  Mit manuellen / explorativen Tests kombinieren Testautomatisierung Hinweise 6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
  • 18. © Zühlke 2012 • Testling sollte gewisse Stabilität erreicht haben • Mindestens zweiten Teststand vorsehen • Zuverlässige Hardware verwenden • KISS (Keep it small and simple) Testautomatisierung Hinweise 6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
  • 19. © Zühlke 2012 • Alle Tests werden automatisiert • Sofortige Kosteneinsparung durch Automatisierung • Capture-Replay ohne Nacharbeit • Ein zugekauftes Werkzeug, das perfekt passt Testautomatisierung Unrealistisch 6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz Unrealistisch!
  • 20. © Zühlke 2012 Eingangsdaten für Berechnung: • Kosten für manuelle Tests – Erstellung der Testfallspezifikationen – Manuelle Testdurchführung • Kosten für automatisierte Tests – Erstellung der Testskripte – Pflege der Testskripte – Automatisierte Testdurchführung – Infrastruktur • Parameter – Anzahl manueller(!) Testläufe – Kosten pro Personentag – Anteil nicht automatisierter Tests ROI von Testautomatisierung Praxisbeispiel Wirtschaftlich Software testen | Matthias Kraaz 6. Dezember 2012
  • 21. © Zühlke 2012 - € 200,000 € 400,000 € 600,000 € 800,000 € 1,000,000 € 1,200,000 € 1,400,000 € 1 2 3 4 Kosten nach Jahren Mit Automatisierung Rein manuell ROI von Testautomatisierung Praxisbeispiel Wirtschaftlich Software testen | Matthias Kraaz 6. Dezember 2012
  • 22. © Zühlke 2012 Man nehme: • Kodierende Tester / testende Entwickler • Unit Test Framework • Mock Generator • Build & Deploy & Run automatisieren Was macht es schwierig: • Abhängigkeiten • Design der Schnittstellen Automatisierung von Komponententests 6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz Test Driver Component under Test Mock
  • 23. © Zühlke 2012 • Eventuell mehrere Integrationsstufen • Herausforderungen je nach Anteil Software / Elektronik Automatisierung von Integrationstests 6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
  • 25. © Zühlke 2012 Verifizierungstests laufen automatisiert während Entwicklung • Vorschau auf Verifizierungsergebnis • Ruhiger Schlaf Automatisierte Verifizierungstests (IV&V) • Zeitdruck, Kosten von Wiederholungen • Test-Infrastruktur der Entwicklung kann wiederverwendet werden • Validierung der Test-Infrastruktur • „Test to verify“ statt „test to kill“ Automatisierte Verifizierungstests Wirtschaftlich Software testen | Matthias Kraaz 6. Dezember 2012
  • 26. © Zühlke 2012 • Fehlerkosten sinken • Softwarequalität steigt • Keine bösen Überraschungen – in der Verifikation oder bei der Abnahme • Testautomatisierung lohnt sich – auch wenn der genaue ROI schwer zu berechnen ist • Wir führen Projekte nur noch mit Testautomatisierung durch – auf allen Test-Ebenen – auch im nicht regulierten Umfeld Testautomatisierung Fazit 6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
  • 27. © Zühlke 2012 Vorteile von Komponenten- und Integrationstests • Weniger Aufwand pro Test • Hohe Testtiefe bequem erreichbar – Hohe Überdeckung von Parametern (Kombinationen, Äquivalenzklassen, Grenzwerte) – Hohe Überdeckung von Zustandsmaschinen – Robustheit-Tests • Früher durchführbar • Häufiger durchführbar • Fehlerursache leichter zu lokalisieren • Leichter automatisierbar Teststufen 6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
  • 28. © Zühlke 2012 Zu wenig Budget Nur Systemtests Optimiert Budget-Verteilung und Testtiefe Untere Teststufen Systemtests Testtiefe Teststufen Wirtschaftlich Software testen | Matthias Kraaz 6. Dezember 2012
  • 29. © Zühlke 2012 Teststufen Wirtschaftlich Software testen | Matthias Kraaz Integrationstests Komponententests 6. Dezember 2012 Systemtests
  • 30. © Zühlke 2012 Nachteile von Komponenten- und Integrationstests • Infrastruktur erforderlich • Automatisierung fast unausweichlich • Aussagekraft muss von oberer Teststufe überprüft werden • Grundstock von Systemtests muss sein Teststufen Wirtschaftlich Software testen | Matthias Kraaz 6. Dezember 2012
  • 31. © Zühlke 2012 Nicht mit der Gießkanne testen! Fokus auf • Sicherheitskritische … • Wichtige … • Komplexe … • Neue … • Durch Bugs aufgefallene … • … Anforderungen • … Software-Komponenten 6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
  • 32. © Zühlke 2012 Nicht mit der Gießkanne testen! Testherleitungsverfahren • Spezifikationsorientiert • Strukturorientiert • Äquivalenzklassen plus Grenzwertanalyse • Entscheidungstabellen • Zustandsbasiert • Anwendungsfallbasiert • Erfahrungsbasiert • … 6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
  • 33. © Zühlke 2012 Statische Analyse einsetzen! Statische Analyse Architektur Metriken Code- Checker Stil Kodier- regeln Laufzeit- fehler Sicherheits- probleme
  • 35. © Zühlke 2012 • Gießkanne weg, systematische Testherleitung • Wenn Reviews Pflicht: Nutzen maximieren, auf Testbarkeit achten • Wenn Teststufen vorhanden: Nutzen maximieren • Design for Testability – Voraussetzung für sinnvolle Teststufen – Erleichterung der Automatisierung – Software-Architektur in Zusammenarbeit von SA und TM • Teststufen einführen • Automatisierung von Systemtests – Automatisierte Verifizierungstests • Parallel: statische Analyse Priorisierung 6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz
  • 36. © Zühlke 2012 Lektüre (1) Wirtschaftlich Software testen | Matthias Kraaz CCElizabeth/Table4Five 6. Dezember 2012
  • 37. © Zühlke 2012 • Daniel Mölle: Stabile Software durch Design for Testability (iX 11/2012, SlideShare) • Matthias Kraaz: Wirtschaftlich Software testen (Kongressband) • Matthias Kraaz: Wirtschaftlich testen (MEDengineering 9-10/2012, SlideShare) • Matthias Kraaz: Qualitätssicherung in Compact Projekten (dotNetPro 02/2012, SlideShare) Lektüre (2) Wirtschaftlich Software testen | Matthias Kraaz CCElizabeth/Table4Five 6. Dezember 2012
  • 38. © Zühlke 2012 • Zusammenarbeit Tester und Entwickler: Design for Testability & Testautomatisierung • Test-Budget optimal nutzen • Im regulierten Umfeld: Nutzen ziehen aus Dingen, die ich ehe machen muss Zur Schmerzlinderung empfehle ich… 6. Dezember 2012Wirtschaftlich Software testen | Matthias Kraaz

Notas do Editor

  1. Wenn Sie hier sitzen, gehe ich davon, dass Sie zumindest einen Teil des hier dargestellten Anforderungsdrucks verspüren.
  2. Wie kann man Systemtests automatisieren?Ganz außen an die echten Systemschnittstellen ranVorteile:Wir testen die Mechanik und gesamte Elektronik immer mit.Keinerlei Änderung am TestlingNachteile:Langsam, aufwendig und fehleranfällig.
  3. Wie kann man Systemtests automatisieren?An die Signalleitungen gehenVorteile:Viel schneller und zuverlässiger.Nachteile:Testinstrumente beschaffen (aus der Testständen für funktionale Tests „ausleihen“)Simulation des Verhaltens der Peripherie kann ziemlich kompliziert seinElektronik muss Zugang ermöglichen (Leiterbahnen nicht im x-ten Layer)Eventuell bekommen die Systemtests den Charakter von Integrationstests. Ihre Aussagekraft muss plausibilisiert werden, zum Beispiel durch manuelle Systemtests oder Vergleich der simulierten mit der echten Peripherie usw.
  4. Wie kann man Systemtests automatisieren?Treiber oder so mit Testschnittstelle patchenVorteile:Kein Ärger mit der Elektronik.Nachteile:Man braucht natürlich auch Infrastruktur zur Kommunikation mit dem Testling.Man testet nicht wirklich das was man ausliefern will.Geänderte Komponenten müssen parallel gepflegt werden.
  5. Wie kann man Systemtests automatisieren?DfT – an vorhandenen Kommunikationskanälen („Testpunkten“)zwischen Treibern und Rest der Software angreifenVorteile:Software wird ohne Änderungen getestet.Nachteile:Nur mit DfT seitens der Softwaremachbar.Und natürlich auch hier Infrastruktur zur Kommunikation mit dem Testling nötig.
  6. Wie kann man Systemtests automatisieren?Zusätzliche „Testpunkte“ inmitten der SoftwareVorteile:Schneller, weil Abkürzungen gegangen werden können.Schneller, weil Fehlerzustände frühzeitig entdeckt werden, nicht erst bei Fehlerwirkung.Nachteile:Tests brechen häufiger.
  7. Wie kann man Systemtests automatisieren?In der Praxis wird man kombinieren.
  8. Gerade die Automatisierung von Systemtests kann schwierig und teuer sein.Design forTestability – ein Begriff aus Elektronikentwicklung – kann Automatisierungskosten drastisch senken oder Testautomatisierung erst möglich machen.
  9. Für den Test von Embedded Devices werden Testinstrumente zur Stimulierung und Messung des Testobjekts (ATE – automatedtestequipment) benötigt. Diese kann man fertig kaufen. Als Beispiel sieht man hier:Einen LabJack U3-HV: ein einfaches IO-Board, das per USB angeschlossen wird. Einfache Bedienung per .NET Schnittstelle.Daneben sieht man ein PXI-Testsystem. PXI ist ein standardisiertes Format für Gehäuse und Steckkarten und stammt aus dem Bereich der Produktionsautomatisierung.Meistens wird noch eine elektrische Adaptierung benötigt, siehe auch nächstes Bild.
  10. Wir ziehen die hier die Anzahl von Testläufen heran, die ohne Automatisierung durchgeführt werden würden.Wir berechnen daherden minimalen ROI der Automatisierung – das spart man auf jeden Fall durch die Automatisierung.Manche ziehen stattdessen die Anzahl der automatisierten Durchführungen heran.Das übersteigert den Nutzen der Automatisierung.Andererseits sind viele Vorteile der Automatisierung bei dieser Berechnung nicht eingepreist.Diese Vorteile sind auch sehr schwierig zu quantifizieren oder vorherzusagen.
  11. Und was wenn die Tester (die keine Entwickler sind) die Komponententests schreiben müssen?
  12. Die Entwicklung kann die Verifizierungstests automatisieren unabhängig davon, ob die IV&V die Verifizierungstests manuell oder automatisiert durchführt.Damit hat die Entwicklung regelmäßig eine Vorschau das Verifizierungsergebnis minus nicht automatisierbarer Verifizierungstests.Bei einem roten Verifizierungstests droht nämlich im Allgemeinen nach der Fehlerbehebung eine vollständige Wiederholung statt wie während der Entwicklung üblich einem partiellem Regressionstest.Das Resultat ist ruhiger Schlaf für das Entwicklungsteam weitgehend ohne Angst vor einem Durchfallen bei der Verifizierung.Die IV&V kann die Verifizierung mit automatisierten Verifizierungstests durchführen.Gründe dafür können der Zeitdruck am Ende der Entwicklung oder aber auch die Kosten für Wiederholungen bei Fehlschlägen der Verifizierung oder bei Aktualisierungen der Software sein.Dazu kann die von der Entwicklung produzierte Test-Infrastruktur wiederverwendet werden.Voraussetzung ist aber meist eine Prüfmittel-Validierung der Test-Infrastruktur.Zudem muss auf den geänderten Fokus „Test toverify“ während der Verifizierung statt „testto kill“ während der Entwicklung geachtet werden.
  13. Lassen Sie Systemtests nicht Ihr einziges Mittel sein.Machen Sie Gebrauch von Komponenten- und Integrationstests als Bestandteil Ihrer Test-Strategie.Problem bei Unit Tests: kodierende Tester, testende Entwickler?
  14. Wenn das Budget nicht reicht und man zu wenig Systemtests hat, braucht man über andere Teststufen nicht nachdenken.Wenn das Budget aber reicht, kann man die Testtiefe überproportional steigern, indem man etwas von dem Budget in Komponenten- und Integrationstests investiert.
  15. Untere Teststufe bilden jeweils Fundament der nächsten Teststufen.Nach unten hin sinkt der Aufwand pro Test und steigt die Anzahl der Tests.Obere Teststufen prüfen stichprobenartig Ergebnisse der unteren Teststufen, haben aber prinzipiell anderen Fokus als untere Teststufe.Komponententests prüfen Verhalten einzelner Komponente, finden eher lokale Fehler in der Komponente.Integrationstests prüfen Zusammenspiel der Komponente, finden eher Schnittstellenprobleme.Durchaus realistisch mehrere Integrationsstufen zu haben.
  16. Systemtests habe auch ihre Vorteile.Systemtests müssen trotzdem sein.
  17. Gehört unbedingt ins Arsenal gegen BugsFindet Bugs, die man mit Tests kaum findetFortgeschrittene Verfahren reduzieren Falschmeldungen
  18. Vorteile von Reviews:Fehlererkennung sehr frühKosten/Nutzen-Verhältnis sehr gutErfolgsrezepte:Nicht die Zeit der Beteiligten mit unwichtigen Details verschwenden. Review-Objekte optimal vorbereiten (Spell Check, Formatierung von Code, Überprüfung von Kodierungsregeln).Inhaltliche Fehler suchen, nicht nur Formfehler.Für das challenging muss man sich nicht endlos tief einlesen: hast Du an X gedacht?Eventuell mit Tool unterstützenWenn Reviews im regulierten Umfeld zwangsweise gemacht werden müssen:Reviews zum Nutzen der Entwicklung einsetzen und nicht als (reine) Pflichtübung ansehen.