Dominique Portmann, Leiter Testengineering

Präsentation zum Thema: "Dominique Portmann, Leiter Testengineering"—  Präsentation transkript:

1 Dominique Portmann, Leiter Testengineering
Wie entscheiden Sie? Go NoGo Dominique Portmann, Leiter Testengineering

2 Das kennen Sie sicher:

3 …und das ?

4 Und Sie leiten Projekte ?
Und, wie entscheiden Sie, was brauchen Sie zum Entscheiden?

5 Was brauchen Sie zum entscheiden?

6 Wie ist das Testen organisiert

7 Die 3 Schlüssel zum Erfolg
Testmanager Prozess Test-Tool(s)

8 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“

9 Wo investieren Manager
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“. 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. 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.

10 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.

11 Was geht beim Sparen schief?
Nicht optimal konfiguriert, nicht an Unternehmung (Prozess, Kultur) angepasst. nicht gepflegt, nicht gewartet und dafür den Projektfortschritt verpasst  Viele Leichen 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 - das Aktive - die Verantwortlichkeit - die Führung es fehlt:

12 Doch zurück zu Ihrem Entscheid:
Sie brauchen Entscheidungskriterien: Kennzahlen, basierend auf einem Prozess

13 Prozess: Noser Way of Testing

14 Der Prozess für Manager
Vorbereiten „Definition of done“, Überprüfbarkeit, Abläufe definieren, Genügend Abdeckung, relevante Tests, Fortschritt Sind wir bereit ? Durchführen Schnell eine Übersicht schaffen, wichtiges zuerst Schnell sog. Blocker identifizieren, Abdeckung sicherstellen, Testfortschritt Ist es reif ? Auswerten Mit Kennzahlen nachweisbar belegen Wertfrei, faktenbasiert, reproduzierbar, Nachweis (Haftung) Wagen wir es ? Analysieren Übersicht schaffen Erfassen der Komplexität sowie des Umfangs Um was geht es Attention Risiko, Kosten, Umfang Frage Kosten / Nutzen

15 Einleitung, Schritt I

16 Schritt I: Kosten Nutzen
Analysieren 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

17 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

18 Risiko 3 27 2 18 1 9 12 6 8 4 Auswirkung Komplexität Auffindbarkeit
RPI 3 27 2 18 1 9 12 6 8 4

19 RPI Der Risiko Prioritäts Index RPI PRIO Testumfang, Testtiefe
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 Abdeckung wesentlicher Pfade, alternative Pfade abwechselnd Abdeckung wesentlicher Pfade, alternative Pfade stichprobenartig und abwechselnd nur Abdeckung, wesentlicher Pfade very low 5 stichprobenartige Abdeckung wesentlicher Pfade

20 Die Strategie

21 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 ist oder nur vermutet werden kann.

22 20 3 60 Cockpit für Schritt I Strategie Risikoanalyse Testorganisation
Analysieren Cockpit für Schritt I Strategie Risikoanalyse Testorganisation Testinfrastruktur Anzahl UseCases Erwartete TestCases Faktor 20 3 60

23 Wie bestimme ich den „Faktor“
Annahme Faktor Bemerkung Schnell und grob 1 Pro UC ein TC Einfach und optimistisch 3 TC‘s für - Normalfall - Variante - eine Ausnahme Vorsichtig 20/RPI Abhängig vom Risikoprioritätsindex Faktor 3

24 Vorbereiten Einleitung Schritt II „Tester“ und „Q-Menschen“ sind nie bereit, sie können die Testvorbereitung sowie die Testinfrastruktur problemlos vergolden.

25 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 Restzeit genau: - entspricht die Reihenfolge des Erstellens dem RPI

26 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 ?

27 Die Abdeckung 2/2 100 % 50 % 90 % 100% des Funktionsumfang
10 % 10 % 10 % 30% erste Testiteration 10 % 10 % 15 % 10 % 45%: 15% Neu, 30% Retest 10 % 10 % 15 % 35%: 25% Neu, 10% Retest 50 % 10 % 60%: 10% Neu, 50% Retest 90 % 10 % 90% getestet, 10% ungetestet

28 Wie beurteilen?

29 Es beginnt mit den Anforderungen

30 Vorbereiten Cockpit für Schritt II

31 Durchführen 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!

32 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

33 Wann ist es reif ? Reifegrad:
- Summe aller Fehler (pro Fehlerklasse) - Summe der offenen Fehler (pro Fehlerklasse) - Anzahl der erfolgreich getesteten Use Cases

34 Cockpit für Schritt III
Durchführen Cockpit für Schritt III

35 Details zu Cockpit

36 Werden Fehler gefunden, flacht die Kurve ab?
Details zu Cockpit Werden Fehler gefunden, flacht die Kurve ab?

37 Hat es noch offene Fehler? (Pro Klasse)
Details zu Cockpit Hat es noch offene Fehler? (Pro Klasse)

38 Details zu Cockpit

39 Beobachtungshilfe für Fehler
Fehlerauswirkung, Schweregrad (Severity) -1- Low: leichter Fehler, betrifft einzelnen Testschritt, Funktion bleibt im Wesentlichen gewährleistet -2- Medium: Betriebsstörender Fehler, Systemfunktion nicht beeinträchtigt Wesentliches funktioniert, wenn auch eingeschränkt -3- High: Schwerer Fehler, Auswirkungen auf Funktion, keine Auswirkung auf 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 39/

40 Das Verwalten von Fehler

41 Schritt IV: die Auswertung
Auswerten Schritt IV: die Auswertung Wie entscheiden Sie, oder: Was beeinflusst den Entscheid?

42 Schritt IV: die Auswertung
Auswerten Schritt IV: die Auswertung „Gutes Testen“ unterscheidet sich von „schlechtem Testen“ dadurch, dass bei „gutem Testen“ noch eine Aussage möglich ist, wie gut das Objekt die Anforderungen erfüllt.

43 Schritt IV, die Auswertung
Auswerten Schritt IV, die Auswertung Testdokumentation nach Normen, z.B. ANSI/IEEE 829 Kennzahlen Protokolle Empfehlung (Auf Basis der Vorgaben / Erwartung)

44 Geeignete Darstellungen
RISIKO Abdeckung: offene Fehler: 1 2 3 Max 1 low 4 Max 1 low plus 3 Medium 5 Max 3 low plus 10 Medium

45 Schritt IV, die Auswertung
Auswerten Schritt IV, die Auswertung Ehrlich: Können Sie jetzt, d.h. in Schritt 4 noch überrascht sein ?

46 Überraschungen unmöglich!
Jederzeit aktuelle Informationen sowie die Übersicht dank Cockpit Erwartetes Resultat gemäss Anforderung

47 Argumentationshilfen für‘s Testing
Stichwort Nutzenargument Beispiel Katastrophe Abwehren von unermesslichen Kostenfolgen Personenschaden Betriebsausfall Reputation Regulatorien Haftung Keine Haftung, da Sorgfaltspflicht nachweisbar erfüllt Risikoanalyse Dokumentierte Testabläufe und Resultate FEMA, MTBF Garantie - Kosten Entlastung nach Übergabe Abnahmetests Abnahmedokument Interdisziplinarität gut qualifiziertes (teures) Personal mehrfach nutzen Bessere Requirements, schnellere Entwicklung, früh eine aktuelle Dokumentation Klare Verantwortlichkeit Entlastung durch Delegation Aktive Testmanagerinnen und Testmanager gestalten, führen und übernehmen so auch Verantwortung für das Gelingen des Projekts Qualität, Review Projekterfolg 4 Augen Prinzip, Zweitmeinung, nicht „nur Entwicklungsleiter“

48 weitere Argumente Stichwort Nutzenargument Beispiel KPI
Kennzahlen zum Führen Abdeckung Durchlaufzeit Anzahl Fehler, Fehlerklassen Restrisiko (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 von Regeln 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.

49 Zusammenfassung Wie reif ist es -> Abdeckung, Anzahl Fehler
Welches Risiko will ich tragen > Strategie, Tiefe, Umfang, Kosten Ist das Testen bereit > Wird das Richtige vorbereitet Wie reif ist es > Abdeckung, Anzahl Fehler Go oder NoGo > faktenbasiert, reproduzierbar