05 [L] Management der Testaktivitäten

Das Testkonzept beschreibt die

1. Ziele

2. Ressourcen

3. Prozesse

eines Testprojekts.

1. Dokumentation von Mittel und Zeitplan des Testprojekts

2. Hilft sicherzustellen, dass die Testaktivitäten ihre festgelegten Kriterien erfüllen

3. dient als Kommunikationsmittel zwischen Stakeholdern

4. Zeigt, dass sich das Testen an die bestehende Testrichtlinie und Teststrategie hält (oder warum nicht)

Das Testkonzept gibt Testern Denkanstöße, um sich mit zukpnftigen Herausfürderungen bzgl. Risiken, Planung, Ressourcen auseinanderzusetzen.

Es bietet die Gelegenheit, um Maßnahmen zu überdenken, die zum Erreichen der Testziele des Projekts erforderlich sind.

1. Der Kontext des Testens (Umfang, Testziele, Einschränkungen, Testbasis)

2. Annahmen und Einschränkungen des Testprojekts

3. Stakeholder

4. Kommunikation (bspw. Formen, Häufigkeit, Dokumentationsvorlagen)

5. Risikoverzeichnis

6. Testansatz (Teststufden, Testarten, -verfahren, Eingangs- und Endekritieren, ...)

7. Budget & Zeitplan

Releaseplanung:

1. Bereitstellung des Produkts

2. Definiert Product-Backlog

3. Verfeinert User-Stories in kleinere Stories

Beitrag involvierter Tester:

1. Erstellen testbarer User-Stories und Abnahmekriterien

2. Erstellen von Projekt- und Qualitätsrisikoanalysen

3. Schätzen Testaufwand

4. Legen Testansatz fest

Iterationsplanung: Plant Abarbeitung des aktuellen Iterationsbacklog.Beiträge von Testern:

1. Nehmen an detaillierten Risikoanalysen der User-Stories teil

2. Bestimmen Testbarkeit der User-Stories

3. Zerlegen User-Stories in (Test-) Aufgaben

4. Schätzen den Testaufwand

5. Verfeinern funktionale und nicht-funktionale Aspekte des Testobjekts

Eingangskriterien definieren die Vorbedingungen für die Durchführung einer bestimmten Aktivität.Wenn die Eingangskriterien nicht erfüllt sind, ist es wahrscheinlich, dass sich die Aktivität

1. als schwieriger, 

2. zeitaufwendiger, 

3. kostspieliger und risikoreicher erweist.

Die Endekriterien legen fest, was erreicht werden muss, um eine Aktivität für abgeschlossen zu erklären.Eingangskriterien und Endekriterien sollten für jede Teststufe definiert werden und unterscheiden sich je nach den Testzielen.

Typische Eingangskriterien sind:

1. Verfügbarkeit von Ressourcen (z. B. Menschen, Werkzeuge, Umgebungen, Testdaten, Budget, Zeit)

2. Verfügbarkeit von Testmitteln (z. B. Testbasis, testbare Anforderungen, User Storys, Testfälle)

3. die anfängliche Qualität eines Testobjekts (z. B. alle Smoke-Tests wurden bestanden).

Typische Endekriterien sind:

1. Messungen der Gründlichkeit (z. B. erreichter Überdeckungsgrad, Anzahl der ungelösten Fehlerzustände, Fehlerdichte, Anzahl der fehlgeschlagenen Testfälle)

2. Testabschlusskriterien (z. B. geplante Tests wurden ausgeführt, statische Tests wurden ausgeführt, alle gefundenen Fehlerzustände werden berichtet, alle Regressionstests sind automatisiert).

3. Aufgebrauchte Zeit oder Budget (falls die Stakeholder das Risiko, ohne weitere Tests in Betrieb zu gehen, geprüft und akzeptiert haben)

In der agilen Softwareentwicklung werden die Endekriterien oft als Definition-of-Done bezeichnet, die die Metriken für ein freizugebendes Element definieren.

Eingangskriterien, die eine User Story erfüllen muss, um mit der Entwicklung und/oder dem Testen zu beginnen, werden als Definition-of-Ready bezeichnet.

Man nimmt Aufwandsschätzungen anhand früherer Aufwandsverhältnisse vor.Bspw. früherer Entwicklungs : Testaufwand = 3 : 2Aktuell sind 600 PT für die Entwicklung geplant.

Folglich werden  

2 * 600 / 3 = 2 * 200 = 400

PT für Test geplant.

Man misst so früh wie möglich Aufwandsdaten im aktuellen Projekt. Diese nimmt man zur Vorhersage kommenden Aufwands.Bspw. prognostiziert man den Aufwand für die kommende Iteration als Durchschnitt der letzten 3 Iterationsdauern.Dieses Verfahren eignet sich besonders für iterative SDLCs.

Breitband-Delphi ist ein Schätzverfahren für Aufwand.

1. Experten nehmen für sich Aufwandsschätzungen vor

2. Falls die Abweichungen unterhalb festgelegter Grenzen liegen, dann ist man fertig

3. Ansonsten diskutiert man die Abweichungen und beginnt wieder bei Punkt 1

Planungspoker ist eine BD-Variante, wo die Schätzungen über Karten mit Zahlen erfolgen.

Drei-Punkt-Schätzung ist ein Schätzverfahren für Aufwand. Hier nehmen Experten 3 Schätzungen vor

1. a = Optimistischer Aufwand

2. m = Erwarteter Aufwand

3. b = Pessimistischer Aufwand

Der finale Aufwand wird als gewichtetes arithmetisches Mittel berechnet

 E = (a + 4m + b) / 6

Vorteil: Die Standardabweichung kann direkt berechnet werden als: 

 SD = (b - a) / 6

1. Risikobasierte Priorisierung

   • Führe zuerst die Testfälle aus, welche die wichtigsten Risiken abdecken

2. Überdeckungsbasierte Priorisierung

   • Führe nach Testfälle nach Anweisungsüberdeckung absteigend aus

3. Überdeckungsbasierte Priorisierung mit zusätzlicher Überdeckung

   • Führe den ersten Testfall nach Anweisungsüberdeckung absteigend aus. Jeder weitere Testfall nach zusätzlicher Anweisungsüberdeckung absteigend.

4. Anforderungsbasierte Priorisierung

   • Führe Testfälle nach Wichtigkeit der überdeckten Anforderungen absteigend aus

Zusätzliche Aspekte welche, die Reihenfolge beeinflussen:

• Abhängigkeiten in Testfällen

  • Falls  Prio(T1) < Prio(T2) aber  T2 von  T1 abhängt, muss  T1  zuerst ausgeführt werden, damit  T2  so früh wie möglich rankommt

•  Verfügbarkeit von Ressourcen

Die Testpyramide ist ein Modell, welches Entwickler in der Testautomatisierung und der Verteilung von Testaufwand unterstützt.Das tut es in, indem es zwei Dinge aufzeigt:

1. Tests haben unterschiedliche Granularität

2. Verschiedene Ziele werden durch verschiedene Grade der Automatisierung unterstützt

   
   

Die Ebenen zeigen verschiedene Gruppen von Tests.Hohe Ebenen zeichnen sich durch

• höhere Komplexität der Tests

• längere Ausführungszeiten

• Mehr Überdeckung durch weniger Tests

• geringere Granularität aus

Geläufig ist eine Teilung in 3 Ebenen. Bspw: 

• UI-Tests, Servicetests, Unit-Tests oder

• End-To-End-Tests, Integrationstests, Unit-Tests

Die Testquadranten sind ein Modell, welches Testarten auf 2 verschiedenen Dimensionen anordnet.Der Zweck ist es das Testmangagement darin zu unterstützen alle geeigneten Testarten und -stufen in den SDLC einzubeziehen.

Q1

Q1

Q2

Q2

Q2

Q2

Q2

Q2

Q3

Q3

Q4

Q4

Q3

1. Die Eintrittswahrscheinlichkeit des Risikos

2. Das Schadensausmaß bei Eintritt

Projektrisiken:

• Beziehen sich auf das Management und die Steuerung des Projekts

• = Alles was am Projekt schlecht laufen könnte

• Bspw. Organisation, Personal, Technische Probleme, Lieferanten

• Wirken sich negativ aus auf: 

  1. Zeitplan

  2. Budget

  3. Umfang

Produktrisiken:

• Beziehen sich auf Qualitätsmerkmale des Produkts

• = Alles was an der Leistung des Produkts schlecht sein könnte

• Mögliche Konsequenzen:

  1. User-Unzufriedenheit

  2. Verlust von Einnahmen oder Ansehen

  3. Schaden für Dritte

  4. Hohe Wartungskosten

Projektrisiko

Projektrisiko

Projektrisiko

Projektrisiko

Projektrisiko

Projektrisiko

Projektrisiko

Projektrisiko

Projektrisiko

Projektrisiko

Projektrisiko

Produktrisiko

Produktrisiko

Produktrisiko

Produktrisiko

Produktrisiko

Produktrisiko

Produktrisiko

Produktrisiko

Bei der Produktrisikoanalyse geht es um die Identifizierung und Bewertung von Produktrisiken.Die Risikobewertung kann quantitativ vs. qualitativ vorgenommen werden.

Quantitativ:  

Risikostufe = Eintrittswahrscheinlichkeit * Schadensausmaß

 Quantitativ:

Ordne die Risiken in einer Matrix an, wo eine Dimension das Schadensausmaß und die andere Dimension die Eintrittswahrscheinlichkeit ist

Sie beeinflussen ...

1. den Umfang der Tests

2. die Bestimmung der Teststufen und Testarten

3. die gewählten Testverfahren und die nötige Überdeckung

4. die Schätzung des Testaufwands

5. die Priorität gewisser Tests

6. die Feststellung ob neben Tests weitere Aktivitäten zur Risikominderung nötig sind

Die Produktrisikosteuerung beschreibt alle Maßnahmen als Reaktion auf ein identifiziertes Risiko. Sie besteht aus der

1. Risikominderung

2. Risikoüberwachung

Maßnahmen zur Risikominderung:

1. Auswahl geeigneter Tester für ein bestimmtes Risiko

2. Auswahl einer geeigneten Unabhängigkeitsstufe der Tester

3. Durchführen von Reviews und statischen Tests

4. Auswahl geeigneter Testverfahren und Überdeckungsgrade

5. Anwendung geeigneter Testarten für die betroffenen Qualitätsmerkmale

6. Durchführung dynamischer Tests, inkl. Regressionstests

1. Metriken zum Projektfortschritt

   • abgeschlossene Aufgaben

   • Ressourcenverbrauch

   • Testaufwand

2. Metriken zum Testfortschritt

   • Fortschritt bei der Testfallrealisierung

   • Fortschritt bei der Vorbereitung der Testumgebung

3. Anzahl der ausgeführten/nicht ausgeführten Testfälle

   • bestandene/nicht bestandene Testfälle

   • Zeit für die Testdurchführung

4. Metriken zur Produktqualität

   • Verfügbarkeit

   • Reaktionszeit

   • mittlere Betriebsdauer bis zum Ausfall (meantime to failure, MTTF)

5. Metriken für Fehlerzustände

   • Anzahl und Prioritäten der gefundenen/behobenen Fehlerzustände

   • Fehlerdichte

   • Fehlerfindungsrate (defect detection percentage, DDP)

6. Metriken zu Risiken

   • verbleibende Risikostufe

7. Metriken zur Überdeckung

   • Anforderungsüberdeckung

   • Codeüberdeckung

8. Metriken zu den Kosten

   • Kosten für das Testen

   • organisatorische Kosten für Qualität

Der Zweck eines Testberichts ist es, Informationen über die Testaktivitäten zusammenzufassen und zu kommunizieren.Typen:

1. Testfortschrittsbericht

2. Testabschlussbericht

1. Testzeitraum

2. Testfortschritt (z. B. vor oder hinter dem Zeitplan), einschließlich aller festgestellten Abweichungen

3. Hindernisse für das Testen und deren Umgehungsmöglichkeiten

4. Testmetriken

5. Neue und veränderte Risiken innerhalb des Testzeitraumes

6. Geplante Tests für den nächsten Zeitraum

1. Zusammenfassung der durchgeführten Tests

2. Bewertung der Tests und der Qualität des Produkts auf der Grundlage des ursprünglichen Testkonzepts (d. h. Testziele und Endekriterien)

3. Abweichungen vom Testkonzept (z. B. Abweichungen vom geplanten Zeitplan, von der Dauer und vom Aufwand).

4. Hindernisse beim Testen und Umgehungen

5. Testmetriken auf der Grundlage von Testfortschrittsberichten

6. Restrisiken, nicht behobene Fehlerzustände

7. Lessons Learned, die für das Testen relevant sind

Unterschiedliche Zielgruppen erfordern beeinflussen

1. den Grad der Formalität und

2. die Häufigkeit der Berichterstattung.

Beispiele:

1. die Berichterstattung über den Testfortschritt an andere Mitglieder desselben Teams erfolgt häufig und informell

2. die Berichterstattung über das Testen für ein abgeschlossenes Projekt einer festgelegten Vorlage folgt und nur einmal erfolgt

1. Mündliche Kommunikation mit Teammitgliedern und anderen Stakeholdern

2. Dashboards (z. B. CI/CD-Dashboards, Taskboards und Burn-Down-Charts)

3. Elektronische Kommunikationskanäle (z. B. E-Mail, Chat)

4. Online-Dokumentation

5. Formale Testberichte

Konfigurationsmanagement bedeutet Versionsverwaltung über Git oder Ähnliches.Es unterstützt testen wie folgt:Alle Konfigurationselemente, einschließlich der Testelemente (einzelne Teile des Testobjekts) werden 

1. eindeutig identifiziert

2. versionskontrolliert

3. auf Änderungen hin verfolgt und

4. mit anderen Konfigurationselementen in Beziehung gesetzt,

damit die Verfolgbarkeit während des gesamten Testprozesses aufrechterhalten werden kann.

• Alle identifizierten Elemente der Dokumentation und Software werden in der Testdokumentation eindeutig referenziert.

Ein Fehlerbericht ist eine Berichterstattung über eine beobachtete Fehlerwirkung.

1. Eindeutige Kennung

2. Titel mit einer kurzen Zusammenfassung der Anomalie

3. Datum, an dem die Anomalie beobachtet wurde, ausstellende Organisation und Autor, einschließlich seiner Rolle

4. Identifikation des Testobjekts und der Testumgebung

5. Kontext des Fehlerzustands

   1. z. B. laufender Testfall

   2. durchgeführte Testaktivität

   3. SDLC-Phase

   4. andere relevante Informationen wie verwendete Testverfahren, Checklisten oder Testdaten

6. Beschreibung der Fehlerwirkung, um eine Reproduktion und Behebung zu ermöglichen, einschließlich der Schritte, die die Anomalie aufgedeckt haben, sowie relevante Testprotokolle, Datenbankauszüge, Screenshots oder Aufzeichnungen

7. Erwartete Ergebnisse und tatsächliche Ergebnisse

8. Schweregrad (Grad der Auswirkung) der Fehlerwirkung auf die Interessen der Stakeholder oder Anforderungen Priorität für die Behebung

9. Priorität für die Behebung

10. Fehlerstatus (z. B. offen, zurückgestellt, doppelt, auf Behebung wartend, auf Fehlernachtest wartend, wiedereröffnet, geschlossen, zurückgewiesen)

11. Referenzen (z. B. auf den Testfall)