Testmanager Lernziele 1.2.1 bis 2.6.3
- + –
Kapitel 1
TM-1.2.1 (K4) Sie können den Testbedarf für ein System analysieren, um die zur Erreichung der Testziele erforderlichen Testaktivitäten und Arbeitsergebnisse zu planen
- + –
Testplanung
- zuständig: Testmanager
- beginnt mit “Einleitung des Prozesses”
- bis Testabschluss
- + –
Testvorgehensweise
- wirtschaftliche Rahmenbedingungen
- organisatorische Rahmenbedingungen
- Teststufen
- Testziele
- Testobjekte
- Testverfahren
- Testteams
- Testüberdeckung
- Testmittel
- Identifizierung der Aktivitäten und Ressourcen
- Testmetriken
- Beziehung zwischen Testbasis, -bedgen, -fällen
- Testwerkzeuge
- Sicherstellen der Rückverfolgbarkeit (RVMatrix)
- + –
Zusammenarbeit mit dem SW-Architekten
- Testumgebung
- Verfügbarkeit der Ressourcen
- Admins TU
- Kosten+ Terminvorgaben
- weiteres
- externe Abhängigkeiten
- + –
Testüberwachung- und steuerung
Fortschritt mit Plan vergleichen
Testplanungs- und überwachungsrahmen
Testarbeitsergebnisse und -aktivitäten für Stakeholder verständlich mit Testbasis in Beziehung setzen
+ – Teststrategie, -ziele, -aktivitäten messen + analysieren
- Testfortschritt
- Endekriterien
- Bezug zum operativen Geschäft
- Stakeholder früh beteiligen
- Aufpassen, dass Zusammenhang zwischen Metriken und Zielen verständlich ist
Dokumentation des aktuellen Status (Teststatus- und Testabschlussbericht)
“Die Teststeuerung steuert den Testprozess, so dass übergeordnete Zielsetzung, Test-strategie und Testziele erreicht werden.”
+ – Wenn nötig Anpassung
- Änderung der Proritäten
- Anpassen von Endekriterien
- Anpassen der Zeitplanung
- Reagieren auf Rahmenbedingungen
- + –
Testanalyse
- Was testen? Testbedingungen
- Analyse der Testbasis, Testziele, Produktrisiken
- + –
Testbed rückverfolgbar
- Testbasis
- strategische Ziele
- Testziele
- weitere Erfolgskriterien gemäß Strakeholder
- + –
Testbed verfolgbar
- Testentwurf
- weitere Arbeitsergebnisse
- beginnt wenn Testbasis vorliegt
- identifiziert durch formale und/oder analytische Verfahren
- können Werte und Variablen enthalten
- + –
Testentwurf
Testfälle entweder konkret oder abstrakt
höhere Teststufen: separate Aktivitäten
niedrigere Teststufen: eine integrierte Aktivität
einige Aufgaben der Testrealisierung könnten in den Testentwurfsprozess integriert werden (z.B. Testdaten)
- Testrealisierung
- Organisation und Priorisierung von Tests durch Testanalysten.
- Umsetzung der Testentwürfe in konkrete Testfälle, Testabläufe und Testdaten.
- Finale Prüfungen kurz vor der Testdurchführung
- Erstellen einer detaillierten Beschreibung der Testumgebung und der Testdaten
- Detaillierungsgrad der Aktivitäten hängt ab vom Detaillierungsgrad der Testbedingungen und Testfälle
- Testdurchführung
- + –
Eingangskriterien
- Testobjekt vorhanden
- Tests entworfen (oder zumindest definiert)
- Werkzeuge einsatzbereit
- Rückverfolgbarkeit etabliert
- Standards für Testprotokollierung und Fehlerberichte definiert
- Durchführung gemäß Testausführungsplan
- Raum für zusätzlicher Tests lassen
- Bei Abweichung vom festgelegten (manuellen) Testvorgehen: Abweichungen dokumentieren
- Hauptaufgabe des Testmanagers: Überwachung des Fortschritts
- + –
Eingangskriterien
- Bewertung von Endekriterien und Bericht
- Teil der Überwachung
- Informationen zur Überwachung pünktlich und genau zur Verfügung stellen
- Häufigkeit und Detaillierungsdgrad der Testberochte sind projektabhängig
- Abschluss der Testaktivitäten
- siehe eigenes Lernziel
TM-1.3.1 (K3) Sie können das Prinzip der Rückverfolgbarkeit anwenden, um die Vollständigkeit und Konsistenz definierter Testbedingungen hinsichtlich der Testziele, Teststrategie und Testkonzept zu prüfen
+ – TM-1.3.2 (K2) Sie können die Faktoren erklären, die sich auf den Detaillierungsgrad der zu spezifizierenden Testbedingungen auswirken können und Sie können die Vor- und Nachteile einer detaillierten Spezifizierung von Testbedingungen erläutern.
- + –
Faktoren
- Teststufe
- Detaillierungsgrad und Qualität der Testbasis
- Komplexität von System und Software
- Projekt- und Produktrisiken
- Beziehungsgeflecht zwischen Testbasis, dem was getestet werden und wie es getestet werden soll
- verwendeter Softwarelebenszyklus
- verwendetes Testmanagementwerkzeug
- Detaillierungsgrad, mit dem Testentwurf und weitere Arbeitsergebnisse spezifiziert werden sollen
- Fähigkeiten und Wissen der Testanalysten
- Reifegrad des Testprozesses und des Unternehmens an sich
- Verfügbarkeit anderer im Projekt involvierter Personen für Beratungszwecke
- + –
Vorteile hoher Detaillierungsgrad
- Testarbeitsergebnissen flexibel zuordnen
- bessere Testüberwachung und -steuerung
- Fehlerprävention früh im Projekt
- Testarbeitsergebnisse für Stakeholder des Fachbereichs verständlicher
- Lenkung anderer Test- und Entwicklungsaktivitäten
- Optimierung der nachfolgenden Aktivitäten
- Basis für klarere horizontale Rückverfolgbarkeit
- + –
Nachteile hoher Detaillierungsgrad
- zeitaufwendig
- wartungsunfreundlichwerden
- Formalität muß vom gesamte Team umgesetzt werden
- + –
Wann hoher Detaillierungsgrad?
- nur minimale Testentwurfsdokumentation
- keine/wenig formale Testbasis
- große, komplexe und riskante Projekt mit intensivem Bedarf an Überwachung und Steuerung
- + –
Wann niedriger Detaillierungsgrad?
- Bezug zwischen Testbasis und Arbeitsergebnissen der Entwicklung kann leicht hergestellt werden
- im Komponententest
- bei weniger komplexen Projekten
- Abnahmetest, auf der Basis von Anwendungsfällen
TM-1.4.1 (K3) Sie können das Prinzip der Rückverfolgbarkeit anwenden, um die Vollständigkeit und Konsistenz von entworfenen Testfällen hinsichtlich der definierten Testbedingungen zu prüfen
TM-1.5.1 (K3) Sie sind in der Lage einen Testausführungsplan zu erstellen, der eventuelle Risiken, nötige Prioritäten, vorhandene Testumgebungen und bestehende Datenabhängigkeiten mit in Betracht zieht. Ihr Testausführungsplan berücksichtigt dabei auch die gegebenen Testziele, die Teststrategie und das Testkonzept und widerspricht ihnen nicht
TM-1.6.1 (K3) Sie können das Prinzip der Rückverfolgbarkeit anwenden, um den Testfortschritt hinsichtlich der Vollständigkeit und Konsistenz mit Testzielen, Teststrategie und Testkonzept zu überwachen
TM-1.7.1 (K2) Sie können erklären, warum das Sammeln genauer und aktueller Informationen im Laufe des Testprozesses für eine korrekte Testberichterstattung und Bewertung der Endekriterien wichtig ist
+ – TM-1.8.1 (K2) Sie können die vier Gruppen von Testabschlussaktivitäten zusammenfassen.
- Testendeprüfung
- Übergabe der Testmittel
- Bewertungssitzungen (Projektretrospektive, Lessons Learned)
- Arbeitsmittel archivieren
- + –
Testplanung
- + –
Kapitel 1.2
+ – TM-2.2.1 (K4) Sie können die relevanten Stakeholder, die Rahmenbedingung und die Erfordernisse eines Softwareprojekts oder -programms ermitteln, wobei sie auf das jeweilige Softwarelebenszyklusmodell Bezug nehmen und daraus die optimalen Testaktivitäten ableiten.
- + –
Stakeholder
- Entwickler, Entwicklungsleiter/manager
- Architekten (SW, DB)
- Businessanalysten
- Geschäftsleitung, Produktmgr, Projektsponsoren
- (Software-) Projektmanager
- Technischer/Kunden-Support, Helpdesk
- direkte/indirekte Anwender
- + –
Schnittstellen zu folgenden Prozessen
- Anforderungsmgmt
- Software-Projektmgmt
- Konfigurations-, Release- und Änderungsmgmt
- Softwareentwicklung, -wartung
- Techn. Support
- Techn. Dokumentation
+ – TM-2.2.2 (K2) Sie verstehen, wie die Aktivitäten und Arbeitsergebnisse im Softwarelebenszyklus das Testen beeinflussen und wie sich umgekehrt das Testen auf die Aktivitäten im Softwarelebenszyklus und die Arbeitsergebnisse auswirkt
- + –
SWE-Modelle
- + –
sequentiell
- Wasserfall
- V-Modell
- W-Modell
- + –
iterativ
- inkrementell (z.B. RAD und RUP)
- evolutionär (z.B. Prototyping)
- Spiralmodell
- + –
agil
- Scrum
- Extreme Programming
- + –
sequentiell
- + –
Merkmale sequentiell:
- Phasen abgeschlossen und aufeinanderfolgend (theoretisch)
- Teststufen
- + –
Merkmale iterativ:
- Mehrere Iterationen, in jeder findet Testen statt
- Regressionstest wird wichtiger (Testautomatisierung!)
- + –
Merkmale evolutionär:
- beim evolutionären Testen sind die Inhalte der Iteration nicht a-priori festgelegt
- bindet Kunden ein (um Anforderungen schrittweise zu verfeinen),
- Risiko: Refactoring der SW Architektur
+ – TM-2.2.3 (K2) Sie können erklären, was für Besonderheiten beim Testmanagement im Zusammenhang mit erfahrungsbasiertem Test und nicht-funktionalem Test zu beachten sind und wie man sie am Besten in den Griff bekommt
- + –
nicht-funktionale Tests
- sind teuer und schwierig/vielfältig
- zu richtiger Zeit risikobaisert integrieren (nicht nach den funktionalen Test)
- eventuell durch Technical Testanalysten (manchmal: Testanalysten) planen lassen
- + –
erfahrungsbasiertes Testen
- ergänzt systematische Testherleitung
- + –
Probleme
- geringe Planung
- geringe Protokollierung
- fehlende Reproduzierbarkeit
- + –
Exploratives Testen
- Test-Charta
- Timeboxing (max 2h), oder auch einfach regelmäßig einplanen
- + –
Ablauf (Sessionbased testing)
- Installations- und Einrichtaktivitäten
- Anwendung kennenlernen
- TF entwerfen, ausführen, protokollieren, Fehlerberichte schreiben
- Nachbesprechung mit weiterer Planung
- + –
Stakeholder
- + –
Kapitel 1.3
+ – TM-2.3.1 (K2) Sie können erläutern, auf welche unterschiedliche Art und Weise risikoorientiertes Testen auf Risiken reagiert
Risiko = Eintrittswahrscheinlichkeit + Schadensausmaß
Das Testteam entwirft, realisiert und führt die Tests dann aus, um die Qualitätsrisiken zu beherrschen.
+ – Beispiele für Qualitätsrisiken
falsche Berechnungen in Berichten (ein funktionales Risiko in Zusammenhang mit der Richtigkeit),
langsame Reaktion auf Benutzereingaben (ein nicht-funktionales Risiko in Zusammenhang mit Effizienz und Antwortzeiten)
schwer verständliche Bildschirme und Eingabefelder (ein nicht-funktionales Risiko in Zusammenhang mit Benutzbarkeit und Verständlichkeit).
Wenn die Tester Fehlerzustände finden, reduzieren sie das Qualitätsrisiko, weil sie das Bewusstsein für vorhandene Fehlerzustände schärfen und die Möglichkeit schaffen, sie vor Release des Systems zu beheben.
Auch wenn die Tester keine Fehlerzustände finden, reduzieren sie beim Testen das Risiko, denn sie stellen sicher, dass das System unter bestimmten (den getesteten) Bedingungen richtig funktioniert.
Beim risikoorientierten Testen dienen die Produktrisiken als Grundlage für die Auswahl der Testbedingungen, Zuweisung von Testaufwand zu den jeweiligen Testbedingungen und zur Priorisierung der erstellten Testfälle.
+ – Risikoorientiertes Testen besteht aus vier Hauptaktivitäten:
- Risikoidentifizierung
- Risikobewertung
- Risikobeherrschung
- Risikomanagement
+ – Produktrisiko steuert
- Testbedingungen,
- Testaufwand
- Priorisierung (von Testfällen)
+ – TM-2.3.2 (K2) Sie können anhand von Beispielen die unterschiedlichen Verfahren zur Erstellung einer Produktrisikoanalyse erklären
- explorativer Test (als sehr einfache Grundlage einer Risikoanalyse)
- + –
“leichte Verfahren”
- PrisMa
- PRAM
- SST
- + –
Eigenschaften leichter Verfahren
- geringe Kosten
- reaktiv + flexibel
- aussagekräftig
- Konsensbildung
- entstanden aus Industrie-Erfahrung
- Einbeziehen der Stakeholder
- Einsatz in frühen Projektphasen möglich
- SST: Anforderungen zwingend
- PrisMa, PRAM: Stakeholderinput reicht, Anforderungen können zusätzlich verwendet werden
- benutzen nur Eintrittswahrscheinlichkeit + Schadensausmaß
- nur qualitativ
- für alle Teams geeignet
- + –
Formale Verfahren
Gefährdungsanalyse (tiefere Analyse von Eintrittswkeit und Schadensausmaß)
Kosten einer Gefährdung (Cost of Exposure): Testkosten mit einbeziehen
Fehler-Möglichkeits- und Einfluss-Analyse (engl. Failure mode and effect analysis (FMEA)): Risiken, Ursachen, Auswirkungen
Qualitätsfunktionendarstellung (engl. Quality Function Deployment (QFD)): House of Quality (Wie, was, warum, wieviel: Korrelationsmatrix)
Fehlerbaum-Analyse (FBA) (engl. Fault Tree Analysis (FTA)): Fehlerwirkung -> Fehlerzuständen -> Fehlhandlung (Root Cause Analysis)
- + –
gängige Eingaben
- Erkenntnisse von Stakeholdern,
- Spezifikationen,
- historische Daten
- + –
gängigen Prozessen
- Risikoidentifizierung,
- Risikobewertung,
- Risikosteuerung
- + –
Gängige Ausgaben
- Liste der Qualitätsrisiken (Risikostufen, Testaufwand),
- Fehlerzustände, die in den Eingabedokumenten (z.B. Spezifikationen) aufgedeckt wurden,
- Fragen, Probleme oder offene Punkte zu Risiken
- Projektrisiken
+ – TM-2.3.3 (K4) Sie können Produktrisiken identifizieren und bewerten und sie können die Risiken sowie deren ermittelte Risikostufe aus der Sicht der wichtigsten Stakeholder des Projekts zusammenfassen
- + –
Stakeholder
wichtigster Erfolgsfaktor: Einbeziehung der richtigen Stakeholder in Risikoidentifizierung, -bewertung
haben eigene Sichten, eigene Prioritäten
fachlich/technisch
- Risikostufe
- quantitativ: Eintrittswahrscheinlichkeit * Schadensausmaß
- qualitativ (z.B. niedrig, mittel, hoch): Kombination durch Risikomatrix
- qualitives Ranking (z.B. 1, 2, 3, 4, ..) : Multiplikation der Rankingwerte
- + –
Risikoidentifizierung
- + –
Liste anlegen (zB durch Brainstorming)
- Experten-Interviews
- unabhängige Bewertungen
- Verwendung von Risikovorlagen
- Projektretrospektiven
- Risiko-Workshops
- Brainstorming
- Checklisten
- Erfahrungen aus der Vergangenheit
- jedes benannte Risiko wird akzeptiert
- Konsens erzielen
- leichte Vorgehensweise: gemeinsames Rankingschema
- + –
Liste anlegen (zB durch Brainstorming)
- + –
Testmanager soll
- Stakeholder verstehen
- Stakeholder einbeziehen
- Stakeholder überzeugen
- Vorgehensweise erläutern und mit Stakeholdern initiieren
- Stakeholder müssen den Wert erkennen
- + –
Nutzen der Risikoanalyse
- Stakeholder identifizieren die Produktrisiken (auch wenn Testbasis unvollständig)
- Effektivität des Testens erhöht sich
- Testbasis wird vervollständigt
- + –
Nutzen des risikoorientierten Testens bewerten:
Ist der prozentuale Anteil wichtiger Fehlerzustände, die das Testteam entdeckt hat, höher als der Anteil weniger wichtiger Fehlerzustände?
Hat das Testteam die meisten wichtigen Fehler früh in der Phase der Testdurchführung gefunden?
War das Testteam in der Lage, den Stakeholdern die Testergebnisse im Hinblick auf die Risiken zu erklären?
Falls das Testteam Tests ausgelassen hat, hatten diese eine geringere Risikostufe als die durchgeführten Tests?
TM-2.3.4 (K2) Sie können die für die ermittelte Risikostufe angemessenen Maßnahmen zur Risikobeherrschung und zum Management von identifizierten Produktrisiken darlegen, und zwar der Produktrisiken, die während des gesamten Softwarelebenszyklus und im Testprozess auftreten können
+ – TM-2.3.5 (K2) Sie können anhand von Beispielen die unterschiedlichen Möglichkeiten der Testauswahl, Testpriorisierung und Aufwandszuweisung erläutern
+ – Testvorgehensweisen sind Methoden zur Testauswahl, Testpriorisierung und Aufwandszuweisung
- + –
analytische Vorgehensweise
- + –
Risikobasiert
- dazu hatten wir oben 3 leichte und 5 formale Verfahren kennengelernt
- + –
Anforderungsbasiert
- Review auf Zweideutigkeit
- Testbedingungsanalyse (durch Genaues Lesen)
- + –
Ursache-Wirkungs-GraphAnalyse (Cause-Effect-Graph)
- kann Testfälle in komplexen Situation drastisch reduzieren
- findet Lücken in der Testbasis
- aufwendig, Tool-Unterstützuhg nötig
- + –
Risikobasiert
- Modellbasiert
- + –
Methodisch
- z.B. checklistenbasiert
- + –
reaktiv
- z.B. explorativer Test
- + –
prozess-/standard-konform
- z.B. agil
- beratungs-unterstützt
- + –
regressionstestorientiert
- bei reifen Anwendungen
- massive Automatisierung des Regressionstests
Priorisierung geschieht in der Planungsphase, abhängig von der Testvorgehensweise, und wird in den folgenden Stufen vererbt
Regelmäßige Anpassung während der Durchführung
- + –
analytische Vorgehensweise
- + –
Kapitel 1.4
+ – TM-2.4.1 (K4) Sie können vorgegebene Testrichtlinien und Teststrategien analysieren und Mastertestkonzepte, Stufentestkonzepte sowie weitere Testarbeitsergebnisse erstellen, in denen die Vorgaben dieser Dokumente vollständig und konsistent umgesetzt sind.
- + –
Testrichtlinie
Zielsetzung des Unternehmens
warum testet das Unternehmen
Testziele (Vertrauen in die Software gewinnen, Entdeckung von Fehlerzuständen, Reduktion von Qualitätsrisiken).
Bewertung von Effektivität und Effizienz des Testens
typischer Testprozess (z.B. nach ISTQB).
Ansätze zur Testprozessverbesserung.
- wer schreibt die Testrichtlinie? “Leitender Testmanager”
- + –
Teststrategie
- Testmethodik/Testprozess.
- Produkt- und Projektrisikomgmt durchs Testen.
- Teststufen.
- Test-Aktivitäten.
- Testeingangs- und Endekriterien.
- + –
Inhalt der Teststrategie
- Integrationsverfahren
- Testspezifikationsverfahren
- Unabhängigkeit des Testens
- verpflichtende & optionale Standards und Normen
- Testumgebungen
- Testautomatisierung
- Testwerkzeuge
- Wiederverwendbarkeit von SW- und Testarbeitsergebnissen
- Fehlernach- und Regressionstests
- Teststeuerung und -berichte
- Testmaße und -metriken
- Fehlermanagement
- Konfigurationsmanagement
- Rollen und Zuständigkeiten
- + –
Testkonzept
- zu testende Objekte und nicht zu testende Objekte
- zu testende und nicht zu testende Qualitätsmerkmale
- Testpläne und Budget für das Testen
- Testdurchführungszyklen und deren Beziehung zum Releaseplan der Software
- Beziehungen und Arbeitsergebnisse der Tester zu anderen Personen oder Abteilungen
- Abgrenzungen zwischen Testobjekten in den jeweiligen Teststufen
- Eingangs-, Unterbrechungs-, Wiederaufnahmekriterien, Endekriterien je Teststufe
- Beziehungen zwischen den Teststufen
- Zuständigkeit für die Durchführung der einzelnen Teststufen
- Testeingaben und Ausgaben der einzelnen Teststufen
- Testprojektrisiken
- übergreifende Verantwortlichkeit für das Testen
- + –
weitere Testarbeitsergebnisse
- Testspezifikation
- Testprotokoll
- Fehlerbericht
- Testabschlussbericht
TM-2.4.2 (K4) Sie können Projektrisiken für ein Projekt analysieren und geeignete Maßnahmen des Risikomanagements bestimmen (d.h. das Risiko beherrschen, Notfallpläne erstellen, das Risiko auslagern und/oder das Risiko akzeptieren)
TM-2.4.3 (K2) Sie können anhand von Beispielen erläutern, wie sich Teststrategien auf die Testaktivitäten auswirken
TM-2.4.4 (K3) Sie können Dokumentationsstandards und -vorlagen für Testarbeitsergebnisse definieren und diese an den Bedarf eines Unternehmens/einer Organisation, an den Softwarelebenszyklus und an ein bestimmtes Projekt anpassen. Bei Bedarf können Sie
vorhandene Vorlagen von Normungsorganisationen für den eigenen Zweck adaptieren
- + –
Testrichtlinie
- + –
Kapitel 1.5
+ – TM-2.5.1 (K3) Sie können eine Testschätzung für alle Testprozessaktivitäten eines Projekts durchführen und je nach Bedarf alle geeigneten Verfahren zur Testschätzung anwenden.
- + –
Probleme
- schwierig und unzuverlässig, wenn Qualität der Software niedrig oder unbekannt
- Nachtests schwierig zu kalkulieren.
- + –
Top-Down + Bottom-Up-Strategien
Intuition & Vermutungen
Erfahrungen aus der Vergangenheit:
Projektstrukturplan (PSP)/ work breakdown structure (WBS)
Team-Schätzungen (Breitband-Delphi, Planning Poker)
Unternehmensstandards und Normen
Anteil am Gesamtprojekt
Organisationsübergreifende Erfahrungen und Metriken (Anzahl von Fehlerwirkungen, Testzyklen, Testfällen, durchschnittlicher Aufwands je Test, Anzahl der Regressionstestzyklen)
Vorstudie
Funktionspunktanalyse (FPA),
Testpunktanalyse (TPA) (dynamische/statische Testpunkt, Kompetenzfaktor, Umgebungsfaktor, Steuerung, Implementierung)
Formeln von Capers Jones (Systemtestfälle = FP ^ 1.2, Abnahme-Testfälle = 1.2*FP)
LoC
geschätzte Entwicklungsaufwände
PSP
Standard-/Breitband-Delphi
3Punkt-Schäzung
+ – TM-2.5.2 (K2) Sie kennen die Faktoren, die die Testschätzung beeinflussen können und können diese anhand von Beispielen erläutern
- + –
Faktoren
Qualitätsniveau des Systems,
Komplexität des zu testenden Systems,
historische Daten, Branchen- und Benchmarkdaten anderer Unternehmen,
Prozessfaktoren (z.B. Teststrategie, Lebenszyklus für Entwicklung und Wartung, Prozessreife, Richtigkeit der Projektschätzung),
Materialfaktoren (z.B. Testautomatisierung, Werkzeuge, Testumgebung, Testdaten, Projektdokumentation, Wiederverwendbarkeit von Testmitteln),
Personalfaktoren (z.B. Führungskräfte, Engagement und Erwartungen des oberen Managements, Fähigkeiten, Erfahrungen, Fachwissen, Verhaltensweisen und Beziehungen im Projektteam, Stabilität des Teams, Verfügbarkeit qualifizierter Lieferanten und Berater, Fachwissen).
Komplexität des Testprozesses (Technik, Organisation; Anzahl der Test Stakeholder; räumlich getrennte Teams, Team-Zusammensetzung)
außergewöhnlicher Aufwand für den Aufbau des Testteams, Training und Einarbeitung
Aufwand für neue Testwerkzeugen (z.B. Technologien, Verfahren, kundenspezifische Hardware, große Anzahl von Testmitteln)
außergewöhnlich detaillierte Testspezifikation, Anwendung neuer Dokumentationsstandards
komplexe Terminierung der Komponentenbeschaffung
- + –
Probleme
- + –
Kapitel 1.6
+ – TM-2.6.1 (K2) Sie können typische testbezogene Metriken beschreiben und vergleichen
- + –
Überwachung der Testplanung und -steuerung
Risiko-, Anforderungs- und sonstige Abdeckungen von Testbasiselementen
Fehlerfindung
Verhältnis geplanter zu tatsächlich aufgewendeten Stunden für die Entwicklung der Testmittel und die Durchführung der Testfälle
- + –
Überwachung der Testanalyse
Anzahl der identifizierten Testbedingungen
Anzahl der Fehlerzustände, die während der Testanalysephase aufgedeckt wurden (z.B. durch Identifikation von Risiken oder Testbedingungen anhand der Testbasis)
- + –
Überwachung des Testentwurfs
prozentualer Anteil der Anforderungen, die von Testbedingungen abgedeckt werden
Anzahl der Fehlerzustände, die während der Testentwurfsphase aufgedeckt wurden (z.B. durch Entwurf von Tests gegen die Testbasis)
- + –
Überwachung der Testrealisierung
- prozentualer Anteil der konfigurierten Testumgebungen
- prozentualer Anteil der geladenen Testdatensätze
- prozentualer Anteil der automatisierten Testfälle
- + –
Überwachung der Testausführung
prozentualer Anteil der geplanten Testfälle, die durchgeführt, bestanden bzw. nicht bestanden wurden
prozentualer Anteil der Testbedingungen, die durch ausgeführte (und/oder bestandene) Testfälle abgedeckt wurden
vorausgesagte Fehlerzustände gegenüber tatsächlich berichteten/behobenen Fehlerzuständen
geplante Überdeckung gegenüber tatsächlich erzielter Überdeckung
- + –
Überwachung von Testfortschritt und -abschluss
+ – Die in der Testplanungsphase festgelegten (und genehmigten) Meilensteine, Eingangs- und Endekriterien abbilden.
Vergleich der geplanten mit den tatsächlich durchgeführten Testbedingungen, Testfällen oder Testspezifikationen, jeweils mit der Angabe, ob sie bestanden wurden oder nicht
Gesamtzahl der aufgedeckten Fehlerzustände, jeweils mit Angabe von Schweregrad, Priorität, Status, betroffenem Teilsystem, oder sonstiger Klassifizierung (siehe Kapitel 4)
Anzahl der Änderungen (Änderungsanträge), die erzeugt, akzeptiert, implementiert und getestet wurden
geplante Kosten gegenüber tatsächlichen Kosten
geplanter Zeitaufwand gegenüber tatsächlich aufgewendeter Zeit
geplante Termine gegenüber tatsächlichen Terminen von Testmeilensteinen
geplante Termine gegenüber tatsächlichen Terminen testrelevanter Projektmeilensteine (z.B. Code-Freeze)
Status von identifizierten Produkt- und Qualitätsrisiken, eingeteilt in reduzierte Risiken, offene Risiken, Hauptrisikobereiche, neue Risiken, die nach der Testanalyse entdeckt wurden, usw.
prozentualer Anteil des Testaufwands, Kosten oder Testzeit, die durch blockierende Ereignisse oder geplante Änderungen verloren gingen
Status der Fehlernachtest und Regressionstests
- + –
Abschluss der Testaktivitäten
prozentualer Anteil der bei der Testdurchführung ausgeführten, bestandenen, nicht bestandenen, blockierten und übersprungenen Testfälle
prozentualer Anteil der Testfälle, die in das Repository für wiederverwendbare Testfälle aufgenommen wurden
prozentualer Anteil der automatisierten gegenüber den noch zu automatisierenden Testfällen
prozentualer Anteil der Testfälle, die in den Regressionstests aufgenommen wurden
prozentualer Anteil von Fehlermeldungen, die geschlossen bzw. nicht geschlossen wurden
prozentualer Anteil der identifizierten und archivierten Arbeitsergebnisse
+ – TM-2.6.2 (K2) Sie können die verschiedenen Dimensionen zur Überwachung und Steuerung des Testfortschritts vergleichen
- Produktrisiken
- Fehler
- Testfallstatus
- Überdeckungsgrade
- Vertrauen in die Softwarequalität
+ – TM-2.6.3 (K4) Sie können im Bezug auf Restrisiken, Fehlerstatus, den aktuellen Status der Testdurchführung, Testüberdeckung und das Vertrauen in die Software Testergebnisse auswerten und über sie berichten, damit Projekt-Stakeholder durch das Gewähren von Einblicken und das Aussprechen von Empfehlungen, Release-Entscheidungen treffen können
- + –
Testbericht
- Kontext
- Testfortschritt
- Produktrisiken
- Ressourcen/Maßnahmen
- Budget
- Risiken
- weitere Planung
- + –
Überwachung der Testplanung und -steuerung