Wie entscheiden Sie?

Dominique Portmann, Leiter Testengineering

Go NoGo

Das kennen Sie sicher:

…und das ?

Und Sie leiten Projekte ?

Und, wie entscheiden Sie,was brauchen Sie zum Entscheiden?

Was brauchen Sie zum entscheiden?

Wie ist das Testen organisiert

Die 3 Schlüssel zum Erfolg

Testmanager

Test-Tool(s)

Prozess

Situation heute (erlebte Praxis)

Tools gibt es wie Sand am Meer…

Prozesse sind (meist) vorhanden,

Doch die Schlüsselrolle des Testmanagers wir verkannt.Testen kann jede und jeder.Wenig definierte Rollen, Testen ist oft ein „Anhängsel“

Wo investieren Manager

Prozesswissen vorhanden, teilweise als „Methode“ verstanden.Geschäftsprozesse belasten nicht das Projektbudget.Hype ist ein muss: ITIL, CMMI, RUP, SCRUM, Agile, V-Modell, W-Modell.

Ideal, da Preisschild und einmalige Investitionen, keine Belastung für Personalbudget. Tool-Hersteller versprechen Nutzen, alle haben Tools.Tools sind Sache der IT und sind geeignete „Sündenböcke“.

Personen kosten, nur Entwickler sind wichtig, sie setzen die versprochenen Anforderungen in Code um.Testen können am Schluss die künftigen Anwenderinnen und Anwender.

Wie wird investiert ?

Tools kosten wenig und versprechen einen grossen Nutzen.Hier argumentieren die Hersteller - managementtauglich.Es wird gerne und viel investiert.

Investitionen erübrigen sich, da Prozesse ja nur „gemalt“ werden müssen.Firmenweite Prozessdokumentationen übersteigen ein Projektbudget.Es wird weder aktiv investiert, noch aktiv gespart.

Personalkosten sind ungern gesehene Budgetposten. Was geschieht nach dem Projekt- und damit Budget- Ende ?Personalbeschaffung übersteigt oft die Budgetkompetenz von Projektleiter.Hier wird selten investiert, aber sehr schnell gespart.

Was geht beim Sparen schief?

Passen nicht auf aktuelle Abläufe, sind zu starr. Werden nicht verbessert und nicht gepflegt. Prozesse unterstützen nicht, sondern „behindern zügiges Arbeiten“. unbenutze Ordner

Nicht optimal konfiguriert, nicht an Unternehmung (Prozess, Kultur) angepasst.nicht gepflegt, nicht gewartet und dafür den Projektfortschritt verpasst Viele Leichen

- das Aktive- die Verantwortlichkeit- die Führung

es fehlt:

Doch zurück zu Ihrem Entscheid:

Sie brauchen Entscheidungskriterien:

Kennzahlen, basierend auf einem Prozess

Prozess: Noser Way of Testing

Der Prozess für Manager

Analysieren

Übersicht schaffenErfassen der Komplexität sowie des Umfangs

Um wasgeht es

Attention Risiko, Kosten,Umfang

Frage Kosten / Nutzen

Vorbereiten

„Definition of done“,Überprüfbarkeit,Abläufe definieren,

GenügendAbdeckung, relevanteTests, Fortschritt

Sind wir bereit ?

Durchführen

Schnell eine Übersicht schaffen,wichtiges zuerst

Schnell sog. Blockeridentifizieren,Abdeckung sicherstellen,Testfortschritt

Ist es reif ?

Auswerten

Mit Kennzahlennachweisbarbelegen

Wertfrei,faktenbasiert,reproduzierbar,Nachweis (Haftung)

Wagen wir es ?

Einleitung, Schritt I

Schritt I: Kosten Nutzen

• Was kann passieren im Fehlerfall• Frage der Haftung• Wie lange „lebt“ das Produkt• In welchem Umfeld wird es eingesetzt• Wie „komplex“ ist das Produkt• Was kostet das Produkt• Gibt es Gesetze, Normen, Vorschriften

Analysieren

Das Risiko

Welche Folgen sind möglich

- Menschenleben- Gesundheit- Finanzielle Auswirkungen- Reputation

Komplexität- Vernetzte Systeme- neue (unbekannte) Technologie- Vairanten und Kombinationen

Auffindbarkeit- wie lange bleibt ein Fehler / Fehlverhalten unerkannt

Risiko

Auswirkung Komplexität Auffindbarkeit RPI3 3 3 273 3 2 183 3 1 9

3 2 2 12

3 2 1 63 1 1 3

2 2 2 8

2 2 1 42 1 1 21 1 1 1

Der Risiko Prioritäts Index RPI

Produkt PRIO RPI Testumfang, Testtiefe

27 very high 1 "alles" in jeder Iteration, sehr gründlich und sehr tief

18

high 2

alles pro zwei Iterationen, gründlich und tief

12 alles pro zwei, drei Iterationen, entweder gründlich oder tief

9

medium 3

wesentliche Abdeckung, in mehreren Iterationen, gründlich und tief wechselnd

8

wesentliche Abdeckung über mehreren Iterationen, Tiefe und Breite abwechselnd

6 wesentliche Abdeckung verteilt auf mehrere Iterationen

4

low 4

Abdeckung wesentlicher Pfade, alternative Pfade abwechselnd

3

Abdeckung wesentlicher Pfade, alternative Pfade stichprobenartig und abwechselnd

2 nur Abdeckung, wesentlicher Pfade

1 very low 5 stichprobenartige Abdeckung wesentlicher Pfade

Die Strategie

Testen vers. Experimentieren

Testen unterscheidet sich von Experimentieren dadurch, dass es beim Testen eine Erwartung gibt die belegt werden soll,während das Ergebnis beim Experimentieren offen istoder nur vermutet werden kann.

Cockpit für Schritt IAnalysieren

Artefakte sind erstellt

1

2

• Strategie• Risikoanalyse• Testorganisation• Testinfrastruktur

AnzahlUseCases

Faktor ErwarteteTestCases

20 3 60

Wie bestimme ich den „Faktor“

Faktor

3

Annahme Faktor BemerkungSchnell und grob 1 Pro UC ein TC

Einfach undoptimistisch 3

TC‘s für- Normalfall- Variante- eine Ausnahme

Vorsichtig 20/RPI Abhängig vomRisikoprioritätsindex

Einleitung Schritt II Vorbereiten

„Tester“ und „Q-Menschen“ sind nie bereit, sie können die Testvorbereitungsowie die Testinfrastrukturproblemlos vergolden.

Wann sind wir bereit ?

Fortschritt: - Wieviele Testszenarien und Testfälle fälle sind zu erwarten- Wieviele Testszenarien und Testfälle sind bereits erstellt- Wie lange dauert die Vorbereitung noch

Abdeckung: - Welche UseCases sind bereits mit Tests abgedeckt, Traceability

Schlüsselfragen für die Führung:einfach: - entspricht der Fortschritt dem Zeitverlauf, der Restzeitgenau: - entspricht die Reihenfolge des Erstellens dem RPI

Die Abdeckung 1/2

Anforderungen Es existieren Tests für:

• Sind die weissen Flecken unkritisch• Entspricht der Fortschritt dem Risiko• Ist der gelbe Teil der kritischste ?• Ist der rosa Teil unkritisch ?

100 %

50 %

10 %

10 %

10 %

15 %

10 %

10 %

10 %

90 %

100% des Funktionsumfang

30% erste Testiteration

45%: 15% Neu, 30% Retest

35%: 25% Neu, 10% Retest

60%: 10% Neu, 50% Retest

90% getestet, 10% ungetestet10 %

10 %

10 %

Die Abdeckung 2/2

15 %

10 %

Wie beurteilen?

Es beginnt mit den Anforderungen

Cockpit für Schritt II Vorbereiten

Vorbereitung

erstelltoffen

01/10/2

011

03/10/2

011

05/10/2

011

07/10/2

011

09/10/2

011

11/10/2

011

13/10/2

011

15/10/2

011

17/10/2

011

19/10/2

011

21/10/2

011

23/10/2

011

25/10/2

011

27/10/2

011

29/10/2

0110%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

TC erwartetAnz. TC erstellt

Schritt III: „Testen“

Die Praxis zeigt immer wieder,dass „von Hand gepflegte“ Systeme in kritischen Momenten nicht mehr gepflegt werden,denn Testen geht immer vor.

Doch genau dann sind Kennzahlen als Entscheidungsbasis besonders wichtig!

Durchführen

Wann ist es reif ?

Fortschritt:

- Wieviele Tests / Testszenarien stehen zur Verfügung - Wieviele Tests / Testszenarien konnten getestet werden - Wieviel konnte erfolgreich getestet werden - Wieviele Testfälle sind noch zu testen - Wie lange dauern die Tests noch

Wann ist es reif ?

Reifegrad:- Summe aller Fehler (pro Fehlerklasse)

- Summe der offenen Fehler (pro Fehlerklasse) - Anzahl der erfolgreich getesteten Use Cases

Cockpit für Schritt III

1 2 3 4 5 6 7 8 90

20

40

60

80

100

120

Summe aller FehlerAnzahl offener FehlerAnz. durchgef. TestsAnzahl getesteter RegAnz TS approx.Anz TS SOLLAnz TS erstelltAnzahl Req

Durchführen

Details zu Cockpit

1 2 3 4 5 6 7 8 90

20

40

60

80

100

120

Anz. durchgef. TestsAnz TS SOLLAnz TS erstellt

Wird genügend getestet ?

Details zu Cockpit

1 2 3 4 5 6 7 8 90

10

20

30

40

50

60

70

Summe aller Fehler

Summe aller Fehler

Werden Fehler gefunden,flacht die Kurve ab?

Details zu Cockpit

1 2 3 4 5 6 7 8 90

5

10

15

20

25

30

35

Anzahl offener Fehler

Anzahl offener Fehler

Hat es noch offene Fehler?(Pro Klasse)

Details zu Cockpit

1 2 3 4 5 6 7 8 90

20

40

60

80

100

120

Summe aller FehlerAnzahl offener FehlerAnz. durchgef. TestsAnzahl getesteter RegAnz TS approx.Anz TS SOLLAnz TS erstelltAnzahl Req

39/

Fehlerauswirkung, Schweregrad (Severity)

-1- Low: leichter Fehler, betrifft einzelnen Testschritt, Funktion bleibtim Wesentlichen gewährleistet

-2- Medium: Betriebsstörender Fehler, Systemfunktion nicht beeinträchtigtWesentliches funktioniert, wenn auch eingeschränkt

-3- High: Schwerer Fehler, Auswirkungen auf Funktion, keine Auswirkungauf andere Funktionen / Systeme

-4- Urgent: Fataler Fehler, Auswirkung auf ganzes System, Testabbruch

Beobachtungsgüte / Reproduzierbarkeit-A- Eindeutig festgestellter, belegbarer und reproduzierbarer Fehler-B- Nicht ohne weiteres reproduzierbar, aber wiederholt aufgetreten-C- Nicht reproduzierbar

Beobachtungshilfe für Fehler

Das Verwalten von Fehler

Schritt IV: die AuswertungAuswerten

Wie entscheiden Sie,oder:Was beeinflusst den Entscheid?

Schritt IV: die AuswertungAuswerten

„Gutes Testen“ unterscheidet sich von„schlechtem Testen“ dadurch, dass bei „gutem Testen“ nocheine Aussage möglich ist,wie gut das Objekt die Anforderungen erfüllt.

Schritt IV, die Auswertung

• Testdokumentation nach Normen, z.B. ANSI/IEEE 829• Kennzahlen• Protokolle

• Empfehlung (Auf Basis der Vorgaben / Erwartung)

Auswerten

Geeignete Darstellungen

5

3

2

4

1

RISIKO Abdeckung: offene Fehler:

0

0

Max 1 low

Max 1 low plus 3 Medium

Max 3 low plus 10 Medium

Schritt IV, die AuswertungAuswerten

Ehrlich:Können Siejetzt, d.h. in Schritt 4noch überrascht sein ?

Überraschungen unmöglich!

Erwartetes Resultatgemäss Anforderung

Jederzeit aktuelleInformationensowie die Übersicht dankCockpit

Argumentationshilfen für‘s Testing

Stichwort Nutzenargument BeispielKatastrophe Abwehren von

unermesslichen Kostenfolgen

PersonenschadenBetriebsausfallReputation

RegulatorienHaftung

Keine Haftung, daSorgfaltspflichtnachweisbar erfüllt

RisikoanalyseDokumentierte Testabläufe und ResultateFEMA, MTBF

Garantie - Kosten Entlastung nachÜbergabe

AbnahmetestsAbnahmedokument

Interdisziplinarität gut qualifiziertes (teures) Personal mehrfachnutzen

Bessere Requirements,schnellere Entwicklung,früh eine aktuelle Dokumentation

Klare Verantwortlichkeit

Entlastung durchDelegation

Aktive Testmanagerinnen und Testmanagergestalten, führen und übernehmen so auch Verantwortung für das Gelingen des Projekts

Qualität,Review

Projekterfolg 4 Augen Prinzip,Zweitmeinung, nicht „nur Entwicklungsleiter“

weitere Argumente

Stichwort Nutzenargument BeispielKPI Kennzahlen zum Führen Abdeckung

DurchlaufzeitAnzahl Fehler, FehlerklassenRestrisiko

(Test-)Strategie

Gezielt und geplant,agieren, statt reagieren,testen nur was nötig

Tests typisieren,Tests priorisieren,Tests immer in Bezug zu Anforderungen

Automatisierung Einsparungen (Schlagwort) Der TM kann aufzeigen, wann und wo es sich rechnet

Vertrauen ist gut,Kontrolle ist besser

Klares Einhalten vonRegeln und Vorgaben

Versionierung, Codereviews,Dokumentation, Statistiken, Kennzahlen

Geteilte Verantwortung

bessere und objektive Beurteilung, weniger Abhängigkeit von Einzelpersonen

TM leitet Prio-board. Hier werden Befunde objektiv beurteilt und priorisiert.Der PL wird nur als „letzte Instanz“ benötigt und kann dann ohne Vorgeschichte entscheiden.

Zusammenfassung

1. Welches Risiko will ich tragen -> Strategie, Tiefe, Umfang, Kosten

2. Ist das Testen bereit -> Wird das Richtige vorbereitet

3. Wie reif ist es -> Abdeckung, Anzahl Fehler

4. Go oder NoGo -> faktenbasiert, reproduzierbar