Upload
heine-rand
View
106
Download
0
Embed Size (px)
Citation preview
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