17. September 2015

__NOTOC__
==Catch the Bug==

==Veranstaltungsdaten==

Datum: Donnerstag, 17. September 2015

Beginn: 18:00 Uhr (ca. 2 Stunden)

Ort: Valyue Consulting GmbH, Weissacher Straße 1, 70499 Stuttgart - Übersicht: [https://www.google.de/maps/search/Weissacher+Stra%C3%9Fe+1,+D+-+70499+Stuttgart+/@48.8208654,9.0915898,17z Google Maps].
Parkplätze ums Haus herum sind vorhanden. 

Die Teilnahme an der Veranstaltung ist wir immer kostenlos. Wir bitten für unsere Planung um eine kurze formlose Anmeldung. Bitte melden Sie sich bis zum 15. September 2015 über die [https://www.asqf.de/fachgruppentermine-anzeige/events/id-17092015-fg-software-test-bawue.html  ASQF Veranstaltungsseite] an.

==Vortrag: "Catch the Bug"==
Ronald Heimberg (QA Systems GmbH)

===Abstrakt===

====Motivation====
Als Ziel jedes Testens von Software muss gelten, Bugs in der Software zu finden. 
Wer diesen grundsätzlichen Auftrag aus dem Auge verliert, investiert falsch in den Aufwand und gibt 
sich zufrieden mit administrativen Tätigkeiten wie bspw., Überdeckungsmaße (Coverage) der 
Testaktivitäten mitzuschreiben. 
Die üblichen Überdeckungsmaße reichen zur Steuerung von Testaktivitäten nicht aus. Das einzig 
taugliche Maß für den Erfolg von Testaktivitäten ist die Anzahl entdeckter Bugs / Failures / Defects. 
Diese Anzahl ist im Voraus völlig ungewiss, d.h. 100 % Fehlerabdeckung sind nicht messbar. 
Wie steuert man nun effizient die Testaktivitäten? 
====Basis====
Vorbedingung lautet, daß eine geeignete Testumgebung im Laufe des Projekts eingerichtet wird. Diese 
Tätigkeit allein verschlingt bereits einige Ressourcen. Wichtiger ist dabei, dass die notwendigen 
Vorgänge eine gewisse Dauer beanspruchen, und der Vorgangsstart wird meist zu spät in die Zukunft 
verlegt. 
====Lösung====
Sobald die Testumgebung eingerichtet ist, lassen sich während der Phase dynamischer Software‐Tests 
verschiedene Teststrategien verfolgen. Hinweise geben die Normen IEC61508 oder ISO26262 reichlich. 
Eine Steuerung der Testaktivitäten kann anhand von Check Points erfolgen. An diesen Check Points wird 
geprüft, welche Ausbeute das derzeitige Testen erbringt und ob ein Strategiewechsel notwendig ist. 
====Ergebnis====
Fließen die Erkenntnisse über mutmaßliche oder faktische Bugs in ein Bug Tracking oder Change 
Management ein, beginnt man, den Return‐On‐Investment des Testens zu messen. Wenn sich dann 
abzeichnet, dass eine Teststrategie keine weiteren Bugs mehr aufdeckt, ist das ein Hinweis, dass die 
Teststrategie gewechselt werden sollte. 
====Ausblick====
Legt man eine Teststrategie beiseite, werden die vorhandenen Testfälle nicht obsolet. Sie werden nun 
einem Regressionstest zugeführt und gewährleisten, dass weitere Änderungen an der Software nicht 
Löcher an anderer Stelle wieder aufreißen. 
====Vortragsessenz====
Steuern von Testaktivitäten und Kosten messen wird nur gelingen, wenn man Testaufwände in Relation 
zu der Anzahl gefundener Fehler setzt. Die üblichen Überdeckungsmaße sind kein Selbstzweck. 

=== Zur Person ===
Ronald Heimberg ist Senior Consultant SW‐Entwicklung in C, C++, Java ● Senior Consultant 
Software‐Entwicklungstools, Statische Codeanalyse und dynamische 
Testtools im Automotive Zuliefererbetrieb ● seit 2009 bei QA Systems 
GmbH tätig im Support, Consulting, Professional Services, Technical Sales 
 
Kontakt:
 Ronald Heimberg 
 rh@qa‐systems.de 
 QA Systems GmbH 
 Schwieberdinger Str. 56  
 70435 Stuttgart, Germany 
 +49 (0) 711 138183‐0