istqb testmanager - firmtec.ch · istqb testmanagergrundlagen [email protected] seite 6 / 52 1....

ISTQB TESTMANAGER Zusammenfassung

Version: 1.0

Donnerstag, 6. Oktober 2016

Autor: Heinz Grob

Inhaltsverzeichnis

1. Grundlagen .................................................................................................................... 6

2. Fundamentaler Testprozess .......................................................................................... 7

2.1. Testprozess Grafik .................................................................................................. 7

2.2. Punkte aus dem Testprozess .................................................................................. 7

2.3. Testanalyse und Design ......................................................................................... 8

2.4. Testrealisierung und Durchführung ......................................................................... 8

2.5. Testauswertung und Bericht ................................................................................... 9

2.6. Abschluss der Testaktivitäten ................................................................................. 9

3. Testen im Softwarelebenszyklus .................................................................................. 10

3.1. Allgemeines V-Modell ........................................................................................... 10

3.2. W-Modell .............................................................................................................. 10

3.3. RUP ...................................................................................................................... 11

3.4. V-Modell XT .......................................................................................................... 11

3.5. Extreme Programming (XP) .................................................................................. 12

3.6. Rapid Application Development (RAD) ................................................................. 12

3.7. Dynamic Systems Development Method (DSDM) ................................................. 13

4. Testdokumentation ...................................................................................................... 14

4.1. Qualitätspolitik und Testpolitik ............................................................................... 14

4.2. Testhandbuch oder Teststrategie .......................................................................... 14

4.3. Testkonzept .......................................................................................................... 15

4.4. Teststufenplan ...................................................................................................... 15

4.5. Weitere Dokumente nach IEEE 829 ...................................................................... 15

5. Testplanung ................................................................................................................. 16

5.1. Teststrategie ......................................................................................................... 16

5.2. Testaufwandschätzung ......................................................................................... 17

5.3. Teststufenplanung ................................................................................................ 18

5.4. Organisation und Koordination von Teststufen ...................................................... 18

5.5. Weitere Aspekte der Testplanung ......................................................................... 19

5.6. Spezielle Testmanagementaufgaben .................................................................... 19

6. Teststeuerung .............................................................................................................. 20

6.1. Initiierung der Testaufgaben ................................................................................. 20

6.2. Überwachung des Testfortschritts ......................................................................... 20

6.3. Reagieren auf Testergebnisse .............................................................................. 21

6.4. Reagieren auf veränderte Rahmenbedingungen ................................................... 21

6.5. Testendbewertung ................................................................................................ 21

6.6. Der Testbericht ..................................................................................................... 22

7. Bewertung und Verbesserung des Entwicklungs- und Testprozesses .......................... 22

7.1. Allgemeingültige Verfahren und Vorgehensweisen ............................................... 22

7.1.1. Total Quality Management (TQM) .................................................................. 23

7.1.2. Kaizen............................................................................................................ 23

7.1.3. Six Sigma ...................................................................................................... 24

7.2. Verbesserung des Softwareentwicklungsprozesses .............................................. 24

7.2.1. Capability Maturity Model Integration (CMMI) ................................................ 24

7.2.2. ISO/IEC 15504 (SPICE) ................................................................................. 25

7.3. Bewertung von Testprozessen .............................................................................. 26

7.3.1. Testing Maturity Model (TMM) ....................................................................... 26

7.3.2. Test Process Improvement (TPI) ................................................................... 28

7.3.3. Systematic Test und Evaluation Process (STEP) ........................................... 29

7.3.4. Critical Testing Process (CTP) ....................................................................... 29

7.3.5. Vergleich der Bewertungs- und Prozessmodelle ............................................ 30

7.4. Audit und Assessment .......................................................................................... 30

7.4.1. Durchführung eines internen Audits oder Assements ..................................... 31

7.4.2. Vorbereitung auf ein Audit oder Assessment durch Externe .......................... 31

8. Abweichungsmanagement ........................................................................................... 32

8.1. Fehler und Fehlerfindung ...................................................................................... 32

8.2. Dokumentation von Abweichungen ....................................................................... 32

8.3. Bearbeitung von Abweichungen............................................................................ 32

8.4. Standartisierte Klassifikation von Abweichungen nach IEEE 1044/1044.1 ............ 33

9. Risikomanagement und risikoorientierter Test ............................................................. 34

9.1. Einführung ............................................................................................................ 34

9.2. Ermittlung des Kontextes ...................................................................................... 35

9.3. Risikoidentifikation ................................................................................................ 35

9.3.1. Grobgranulare Risikokategorisierung ............................................................. 35

9.3.2. Techniken und Hilfsmittel ............................................................................... 36

9.4. Risikoanalyse und –einstufung.............................................................................. 36

9.4.1. Feingranulare Risikokategorisierung .............................................................. 36

9.4.2. Quantitative und qualitative Risikoeinstufung ................................................. 36

9.4.3. Risikoeintrittsindikatoren ................................................................................ 37

9.4.4. Risikoinventar ................................................................................................ 37

9.5. Risikosteuerung und –beherrschung ..................................................................... 38

9.6. Risikoüberprüfung und –überwachung .................................................................. 38

9.7. Risikoorientierte Testkonzepterstellung und Testpriorisierung .............................. 38

9.8. Quantitative Fehlzustandsanalysen ...................................................................... 39

9.8.1. Fehlzustandsart- und –auswirkungsanalyse (FMEA) ..................................... 39

9.8.2. Fehlerzustandsart-, Auswirkungs- und Ausfallbedeutungsanalyse (FMECA) . 40

9.8.3. Fehlerzustandsbaumanalyse (FTA) ............................................................... 40

9.8.4. Risikobasierte Testaufwandoptimierung ......................................................... 41

10. Mitarbeiterqualifikation .............................................................................................. 41

10.1. Individuelle Fähigkeiten ..................................................................................... 41

10.2. Fachliche Teamrollen ........................................................................................ 41

10.3. Soziale Teamrollen ............................................................................................ 43

10.4. Faktor Kommunikation ....................................................................................... 43

10.5. Faktor Motivation ............................................................................................... 43

10.6. Ethik Kodex ....................................................................................................... 43

11. Testmetriken ............................................................................................................ 44

11.1. Einführung ......................................................................................................... 44

11.2. Etwas Messtheorie ............................................................................................ 44

11.3. Definition und Auswahl von Metriken ................................................................. 44

11.4. Darstellung von Messwerten ............................................................................. 45

11.5. Einzelne Testmetriken ....................................................................................... 45

11.5.1. Testfallbasierte Metriken ............................................................................ 45

11.5.2. Testbasis- und testobjektbasierte Metriken................................................. 45

11.5.3. Fehlerbasierte Metriken .............................................................................. 46

11.5.4. Kosten und aufwandsbasierte Metriken ...................................................... 46

11.5.5. Beurteilung der Testeffektivität ................................................................... 46

11.6. Restfehlerabschätzung und Zuverlässigkeit ...................................................... 47

11.6.1. Restfehlerwahrscheinlichkeit ...................................................................... 47

11.6.2. Zuverlässigkeits-Wachstumsmodelle .......................................................... 47

12. Werkzeuge zur Unterstützung des Testprozesses .................................................... 47

12.1. Motivation .......................................................................................................... 47

12.2. Typen und Nutzer von Testwerkzeugen ............................................................ 48

12.2.1. Werkzeuge für Management und Steuerung von Tests .............................. 48

12.2.2. Testgeneratoren ......................................................................................... 48

12.2.3. Analysewerkzeuge ..................................................................................... 48

12.2.4. Testdurchführungswerkzeuge .................................................................... 48

12.2.5. Weitere Werkzeuge .................................................................................... 48

12.3. Bewertung und Auswahl von Testwerkzeugen .................................................. 49

12.3.1. Grundsätzliche Entscheidung über Einsatz eines Werkzeugs .................... 49

12.3.2. Identifikation von Anforderungen ................................................................ 49

12.3.3. Evaluation .................................................................................................. 50

12.3.4. Auswahl des zu beschaffenden Werkzeugs ............................................... 50

12.4. Einführung von Werkzeugen ............................................................................. 50

12.4.1. Werkzeuge und notwendige Prozessreife .................................................. 50

12.4.2. Pilotprojekt ................................................................................................. 50

12.4.3. Verbreitung................................................................................................. 50

13. Normen und Standards ............................................................................................ 51

13.1. Ziele und Positionierung .................................................................................... 51

13.2. Firmenstandards ............................................................................................... 51

13.3. Best Practices und technische Spezifikationen .................................................. 51

13.4. Branchenspezifische Normen und Standards .................................................... 51

13.5. Allgemeingültige Normen und Standards........................................................... 52

Historie

Version Datum Bemerkungen

1.0 06.10.2016 Initiale Version

Template Version: 1.0

Disclaimer:

Dieses Dokument wurde von FirmTec Solutions AG mit grösstmöglicher Sorgfalt erstellt.

Dennoch übernimmt die FirmTec Solutions AG keine Gewähr für die Aktualität,

Vollständigkeit und Richtigkeit der bereitgestellten Seiten und Inhalte.

Für Fragen und Anregungen stehen wir Ihnen gerne unter der Emailadresse [email protected]

zur Verfügung.

mailto:[email protected]

ISTQB TESTMANAGERGrundlagen

[email protected] Seite 6 / 52

1. Grundlagen

Massnahmen zur Verbesserung der Softwarequalität

Definierte Softwareentwicklungsprozesse

Definierter Testprozess

Einsatz von Metriken und Qualitätskennzahlen

Einsatz von formalen Methoden

Methoden zur Ermittlung und Durchführung von Testfällen

Methoden zur statischen Prüfung

Via Testorakel wird das Sollverhalten der Applikation ermittelt, Anforderungsdokumente

und/oder formale Spezifikation, sowie Benutzerhandbücher dienen als Wissensgrundlage

hierfür.

Es werden unterschiedliche „Fehler“ definiert:

Fehlhandlung -> Person programmiert Fehlerhaft

Fehlerzustand -> Durch die Fehlhandlung entsteht ein Fehlerzustand der zu einer nach aussen Sichtbaren Fehlerwirkung führt.

Fehlerwirkung -> siehe oben, allerdings ist ein Fehlerzustand nicht immer sichtbar.

Mit Testen ist der gesamte Prozess gemeint welcher ein Programm systematisch prüft.

Der fundamentale Testprozess besteht aus:

Testplanung und Steuerung

Testanalyse und Testdesign

Testrealisierung und Testdurchführung

Testauswertung und Bericht

Abschluss der Testaktivitäten

Die Teststufen innerhalb eines Testzyklus sind:

Komponententest

Integrationstest

Systemtest

Abnahmetest

Es werden folgende Testarten unterschieden:

Funktionaler Test

Nicht funktionaler Test

Strukturbezogener Test

Änderungsbezogener Test

Es bestehen diese unterschiedlichen Testarten:

Dynamischer Test -> White- und Blackbox Verfahren


ISTQB TESTMANAGERFundamentaler Testprozess


Statischee Test -> Reviews

Grundlegende Aspekte des Testmanagements:

Testplanung

Teststeuerung

Berichtswesen

Fehleränderung

Konfigurationsmanagement

Wirtschaftlichkeit des Testens

2. Fundamentaler Testprozess

Ein früher Start der Planung für das Testen ist unabdinglich, hierfür müssen die Aufgaben

und Zielsetzungen sowie die Ressourcen bekannt sein.

All diese Informationen werden zusammen mit den verwendeten Hilfsmitteln und

Werkzeugen in einem Dokument beschrieben, dem sogenannten Testkonzept.

2.1. Testprozess Grafik

Die Grafik zeigt den fundamentalen Testprozess:

2.2. Punkte aus dem Testprozess

Die Intensität der Tests wird bestimmt durch das Testverfahren und den angestrebten

Überdeckungsgrad, anhand dessen das mögliche Ende der Tests festgelegt wird.




Tests sollten priorisiert werden um bei Zeit- und Ressourcenmangel die kritischen Punkte

zuerst durchgeführt werden können.

Die Basis von Teststeuerungen sind Mitarbeiterberichte sowie das während des Testens

gewonnene Zahlenmaterial, hiermit kann der Testprozess gelenkt werden.

2.3. Testanalyse und Design

Besteht aus:

Testbedingungen (test condition), welche beschreiben was und wie intensiv getestet wird

Testfällen, welche den eigentlichen Test beschreiben.

Basisüberlegung für Testbedingungen

Was ist wie zu testen?

Wie detailiert sind die Anforderungen an die Applikation bekannt (allgemeine Definitionen ergeben eher allgemein gehaltene Tests)?

Wie bekannt sind die Risiken?

Welche Anforderungen hat das Management bezüglich Berichterstattung?

Auf welche Testfälle kann unter Umständen bei Zeit- und Budgetmangel verzichtet werden?

Entwurf der Testfälle

Zu einem Testfall gehört:

Bestimmen der Ausgangssituation

Spezifikation der Testdaten

Erwartete Ausgaben

Nachbedingungen die nach Ausführung des Tests gelten

Um erwartete Ergebnisse und das Sollverhalten zu bestimmen wird das Testorakel

herbeigezogen. Das Testorakel basiert auf der Spezifkation der Testobjekte.

Testfälle sind für alle Teststufen zu erstellen.

Ein Standard um Testbedingungen und Testfälle zu dokumentieren ist der Standard IEEE

829.

Der Einsatz von verschiedenen Reviews (z.B. statische Codeanalyse) ergänzt den Prozess

der Testanalyse und des Testdesigns.

Ein weiterer wichtiger Punkt ist die frühzeitige Bereitstellung der Testinfrastruktur.

2.4. Testrealisierung und Durchführung

Testrealisierung




Die erstellten Testfälle müssen in Testszenarien und Testsequenzen zusammengefasst

werden um eine klare Organisation zu gewährleisten. Dies erfolgt in einem Testplan.

Festlegung der Reihenfolge

Fortsetzung des Ablaufs im Fehlerfall

Eingangsbedingungen prüfen

Korrekte Testumgebung

Verantwortlichkeit der Personen kennen

Regeln und Vorgehensweise ist klar

Bekannte Standards festlegen

Flexibel auf Änderungen reagieren

Testdurchführung

Basis ist der Vergleich von erwarteten zu tatsächlichen Ausgaben. Anhand des

Abweichungsmanagements sind entsprechende Daten beim Feststellen von

Fehlerwirkungen zu dokumentieren.

Sind Unterschiede festgestellt worden so ist zu kontrollieren ob die Testspezifikation korrekt

ist da:

falsche Testdaten vorhanden sein können

ungenaue Testdokumentation vorhanden ist

der Test falsch durchgeführt worden ist

Die Durchführung der Tests ist zu protokollieren.

2.5. Testauswertung und Bericht

In dieser Phase des Testens sind Informationen zu sammeln und zu bewerten die

anschliessend in einem Bericht zusammengefasst werden.

Dieser dient zur Überwachung des Testfortschritts sowie zur Entscheidung über das Ende

des Tests.

Testberichte sind für jede Teststufe anzuwenden.

Der Bericht beinhaltet:

Ausgeführte Testfälle

Anzahl ausgeführte Fehlerwirkungen

Anzahl der Änderungswünsche (Change Requests)

Unterschied zwischen geplantem und tatsächlichem Testaufwand

Identifizierte Risiken

Prozentualer Anteil der Testzeit welcher von blockierten Testfällen verloren ging

Aufwand für Fehlernachtests

2.6. Abschluss der Testaktivitäten

Es sind grundsätzlich vier Aspekte für die abschliessenden Testaktivitäten zu

berücksichtigen:


ISTQB TESTMANAGERTesten im Softwarelebenszyklus


Sicherstellen das alle geplanten Testaufgaben auch wirklich abgeschlossen sind.

Die Berichte müssen den verantwortlichen Entscheidungsträgern zugestellt sein.

Die gemachten Erfahrungen sind rückblickend zu analysieren

Sicherung der gemachten Tests und deren Erkenntnisse (Konservierung).

3. Testen im Softwarelebenszyklus

Das Testen ist ein wichtiger Bestandteil im gesamten Softwareentwicklungsprozess.

Zum besseren Verständnis der verschiedenen Entwicklungsprozesse wird zwischen

folgenden unterschieden:

Sequenzielle Modelle, die einzelnen Aktivitäten erfolgen nacheinander

Iterative Modelle, es entstehen zuerst Teilprodukte welche nach und nach zum Endprodukt zusammengesetzt werden

3.1. Allgemeines V-Modell

Es werden Teststufen und der Zusammenhang mit den entsprechenden Analyse-, Entwurfs-

und Spezifikationsphasen hervorgehoben. Die vorbereitenden Testaktivitäten (z.B.

Testplanung, Testspezifikation) werden im Modell nicht deutlich dargestellt.

3.2. W-Modell

Im W-Modell werden parallel zu den Analyse-, Entwurfs- und Spezifikationsphasen die

vorbereitenden Testaktivitäten zu den einzelnen Teststufen klar hervorgehoben. Auch wird

zwischen der Testdurchführung/Auswertung und dem Debugging unterschieden. Der

Testprozess ist eng mit dem Entwicklungsprozess verzahnt.




3.3. RUP

Rational Unified Process besteht aus den Phasen:

Konzeptualisierung (Inception)

Entwurf (Elaboration)

Konstruktion (Construction)

Übergang (Transition)

Innerhalb der Phasen erfolgt die Aufteilung in mehrere Iterationen. Jede Iteration produziert

eine ausführbare und getestete Version und fügt der Vorherigen ein Inkrement dazu.

Die Testaktivitäten beginnen bereits in der Konzeptualisierung mit der Testplanung.

3.4. V-Modell XT

Dieses Modell (XT steht für extreme Tailoring) ist eine Erweiterung des V-Modells welches

eine Anpassung des klassischen V-Modells in einem Projekt vorsieht.




Es wird für jede Entwicklungsphase festgelegt wer, wann, was zu tun hat. Es werden

Aktivitäten und Verantwortlichkeiten definiert.

Zwei Punkte die beim V-Modell XT besonders hervorzuheben sind:

Das Tailoring, die Anpassung des Modells an ein konkret durchzuführendes Projekt

Die explizite Einbindung des Auftraggebers und Kunden in die Projektplanung

Dieses Modell erlaubt eine flexible Anpassung an die gegebene Projektkonstellation.

In diesem Modell ist keine Rolle als Testmanager explizit definiert, diese Arbeit ist auf

verschiedene andere Rollen verteilt.

3.5. Extreme Programming (XP)

Beim Extreme Programming steht das Testen von Beginn an im Mittelpunkt der Entwicklung

(test first). Testfälle dienen als Spezifikation, Iterationen erfolgen in sehr kurzen Zeiträumen.

Der Kunde ist für den Akzeptanztest bei jedem Release verantwortlich.

Das Hauptgewicht des Testens liegt allerdings auf den Unit Test der einzelnen Bausteine.

3.6. Rapid Application Development (RAD)

Basis des RAD ist die toolunterstützte Softwareentwicklung auch CASE, Computer Aided

Software Engineering genannt.

Neben der intensiven Werkzeugunterstützung wird die Verkürzung durch iterative

Entwicklungsschritte erreicht.

Explizite Rollen zum Testen oder dem Testmanagement sind nicht definiert.

Es existieren SWAT (Skilled Workers with Advanced Tools) Teams aus 2 bis 6 gut

ausgebildeten Entwicklern.




3.7. Dynamic Systems Development Method (DSDM)

DSDM hat grosse Ähnlichkeit zu SCRUM, die Methode basiert auf den neuen Grundpfeilern:

Softwareentwicklung erfolgt im Team

Das Team entscheidet

Regelmässige Lieferungen

Zusätzliche Lieferungen müssen für den Kunden im Vergleich zu vorherigen Lieferungen zusätzlichen Geschäftswert haben

Lösungen werden iterativ und inkrementell erarbeitet

Änderungen müssen leicht zurückgenommen werden können

Anforderungen werden auf hohem Niveau festgeschrieben

Testen erfolgt im gesamten Entwicklungsprozess

Zusammenarbeit und Koorperation ist sehr wichtig

Time Boxing:

Technik oder Vorgehen aller Aktivitäten in vorab festgelegten Zeiträumen.

Zeitüberschreitungen werden nicht akzeptiert

MoSCoW Prinzip:

Must have -> Fundamental wichtig für den Projekterfolg

or

Should have -> Wichtige Anforderung, Projekterfolg ist nicht direkt davon abhängig

Could have -> Kann weggelassen werden ohne das Projekt entscheidend zu beeinflussen

or

Won’t have -> Wird nicht umgesetzt


ISTQB TESTMANAGERTestdokumentation


4. Testdokumentation

Die Testdokumentation ist in folgende Hierarchie gegliedert:

Qualitätspolitik, ist die Basisebene in welcher die strategische Bedeutung der Qualität innerhalb einer Unternehmung definiert ist

Testpolitik, Grundlage für die allgemeine Aussage von Softwarequalität, ist Bestandteil der Qualitätspolitik, Bedeutung des Testens für die Qualitätssicherung und die zu erfüllenden Aufgaben

Testhandbuch (oder Teststrategie), beschreibt die Richtlinien für alle Testaktivitäten in den verschiedenen Organisationseinheiten, sowie in einzelnen Teststufen

Testkonzept, abgeleitet aus dem Testhandbuch wird das Testkonzept erstellt, konkrete Anwendung des Testhandbuchs, gilt für ein Entwicklungsprojekt

Testplan, Planungsvorgaben des Testmanagers, beschreibt in welchem Ablauf welche Dokumente erstellt werden.

4.1. Qualitätspolitik und Testpolitik

Die Qualitätspolitik drückt aus welche Bedeutung Qualität für das Unternehmen hat und

welchen Qualitätsanspruch es an seine Produkte, Dienstleistungen und Prozesse stellt.

Daraus werden Richtlinien, Vorgaben und Hinweise zur Realisierung dieser Vorgaben,

sowie Prüfmechanismen um diese Ziele zu erreichen, erstellt.

Testpolitik hat Gültigkeit für ein ganzes Unternehmen oder eine Teilorganisation. Zu

folgenden Themen hat die Testpolitik Grundlagen zu schaffen:

Definition des Begriffs Testen im Unternehmen

Darstellung des Testprozesses

Vorgaben zur Bewertung des Testprozesses

Qualitätsziele

Ansatz zur Testprozessverbesserung

4.2. Testhandbuch oder Teststrategie

Ein Testhandbuch kann langfristige unternehmensweite Gültigkeit haben oder gemeinsame

Regelungen für mehrere ähnliche Projekte beinhalten. Im Minimalfall beschreibt es nur die

Vorgehensweise für ein einzelnes Projekt.

Das Testhandbuch gibt Antworten auf folgende Fragen:

Testplanunung und Testmanagement, wie werden aus Informationen zum Produktrisiko die einzelnen Testaktivitäten abgeleitet, welche Standards sind einzuhalten, wie sehen die Testumgebungen aus, welche Ansätze zur Testautomatisierung existieren, Strategien zur Wiederverwendung von Testware in den einzelnen Teststufen, wie werden Regressionstests geplant?

Teststufen und Testphasen, welche Teststufen und Testphasen sind in einem Projekt vorgesehen, gilt der allgemeine Testprozess in jeder Teststufe, welches sind die Eintritts- und Austrittskriterien einer Teststufe, wer führt die Tests durch (z.B. Entwickler), welche Teststufe ist verantwortlich um die Anforderungen/Risiken abzudecken?


ISTQB TESTMANAGERTestdokumentation


Integrationsverfahren, wie werden die Komponenten des Systems integriert, welche Testumgebungen bestehen, welche Strategie wird eingesetzt?

Teststeuerung und Testkontrolle, welche Ressourcen stehen zur Verfügung, wie wird der Fortschritt verfolgt, welche Berichte werden erstellt und wer ist der Empfänger, welche Metriken sind zu verwenden?

Abweichungs- und Konfigurationsmanagement, wie wird das Abweichungsmanagement organisiert, wie funktioniert das Konfigurationsmanagement (Versionierung, Archivierung)?

4.3. Testkonzept

Das Testkonzept ist das Planungsdokument des Testprojektes, es setzt die Qualitäts- und

Testpolitik in die Projektrealität um.

Das Testkonzept muss im Gegensatz zu strategischen Dokumenten wie die Testpolitik und

das Testhandbuch häufig geändert werden, da sich während eines

Softwareentwicklungsprozesses die Anforderungen laufend ändern.

Das Testkonzept bildet das Grundgerüst für die Testfallspezifikation.

Der Standard IEEE 829 spezifiziert die Struktur des Testkonzepts sowie die zu erzeugenden

Dokumente aus dem Testprojekt.

4.4. Teststufenplan

Der Teststufenplan beschreibt im Detail die Aufgaben, den Zeitplan und die Meilensteine pro

Teststufe.

Das Testkonzept stellt den Rahmen für die Beschreibung aller Teststufen dar und sorgt für

die Konsistenz der Stufenpläne zueinander.

Das Tailoring wird ebenfalls im Teststufenplan beschrieben.

4.5. Weitere Dokumente nach IEEE 829

Folgende Dokumente sind ergänzend zum Testkonzept nach IEEE 829 zu sehen:

Stufendesign, verfeinert die projektspezifische Teststrategie für eine einzelne Teststufe

Stufentestfallspezifikation, beschreibt im Detail einen oder mehrere Testfälle welche im Stufendesign aufgeführt sind.

Stufentestvorgehensspezifikation, beschreibt die Abfolge eines oder mehrerer Testfälle in Form eines Szenarios

Stufentestprotokoll, Protokoll der pro Teststufe ausgeführten Testfälle

Abweichungsmeldung, Information die zur Meldung einer Abweichung notwendig sind

Stufentestverlaufsbericht, Status der Tests innerhalb einer Stufe

Stufentestergebnisbericht, Berichterstattung bei Abschluss einer Teststufe


ISTQB TESTMANAGERTestplanung


5. Testplanung

Wesentliche Aufgaben der Testplanung sind

Die Ausarbeitung einer passenden Teststrategie

Die Planung der aus der Strategie abzuleitenden Aktivitäten in den einzelnen Teststufen

Die Schätzung des Aufwands für diese Aktivitäten

Die Abbildung der Aktivitäten in eine Testorganisation

5.1. Teststrategie

Aufgabe der Teststrategie ist

die Identifikation der Testziele (funktional und nicht-funktional)

die Zuordnung der einzusetzenden Testaktivitäten und Testverfahren

die Verteilung der Ressourcen auf die Aktivitäten

die Anordnung der Aktivitäten in eine sinnvolle Reihenfolge

Im Fokus steht die Minimierung des Produktrisikos.

Beginn der Testaktivitäten

Es gibt zwei Arten zu ermitteln welche Aktivität in welcher Phase des Projektes

durchzuführen ist:




Präventive Strategien zielen darauf ab durch frühzeitige Testplanungs und –entwurfstätigkeiten die Enstehung von Fehlern zu minimieren, bzw. Fehler frühzeitig zu finden

Reaktive Strategien beginnen mit der Testplanung und insbesondere dem Testfallentwurf erst nach Vorliegen des Systems

Abgrenzung der Aufgaben des Testprojekts

Festlegen welche Komponenten des Systems getestet werden müssen und welche nicht

Die Testziele legen fest welche Qualitätsmerkmale in welcher Weise im Test nachgewiesen werden

Bestimmen der nicht funktionalen Qualitätsmerkmale

Qualitätsziele bestimmen

Der Testmanager bestimmt welche Projektziele explizit nicht Bestandteil des Testkonzepts sind.

Art und Umfang des Tests

Festlegung von Testverfahren

Priorisierung der Testziele

Kosten und Nutzen der Tests abwägen

5.2. Testaufwandschätzung

Es existieren zwei grundlegende Testaufwandschätzungen:

Top-Down Es wird der Gesamtaufwand für den Test aus geeigneten Projektparametern abgeleitet und anschliessend auf die einzelnen Aktivitäten verteilt.

Bottom-Up Die Einzelaktivitäten werden getrennt geschätzt und anschliessend summiert.

Die Schätzung des Aufwandes basiert auf folgender Checkliste:

Testplanung

Testvorbereitung

Personelle Besetzung

Testspezifikation

Testautomatisierung

Testdurchführung

Dokumentation

Fehleranalyse & Fehlernachtest

Testmetriken

Kommunikation im Testteam

Es existieren folgende Schätzarten:




Expertenschätzung, ein einfacher formaler Prozess ist das Delphi und Breitband Delphi Verfahren

Nutzung von historischen Daten, rsp. Vergleichsdaten von durchgeführten Projekten

Formel- und metrikbasierte Schätztechniken wie prozentuale Schätzung, Funktionspunktanalyse (FPA), Testpunktanalyse (TPA)

Dynamische Testpunkte

5.3. Teststufenplanung

Es wird zunächst ein grober Zeitplan aller Testaktivtäten auf Meilensteinebene, der

sogenannte Masterplan angelegt. Anschliessend wird basierend auf den Meilensteinen für

jede Stufe eine erste Version des Zeit- und Aktivitätenplans (Teststufenplan) erstellt.

Typischerweise findet ein Teststufenplan seine Realisierung in einem mit

Zusatzinformationen hinterlegten Gantt-Diagramm, welches folgende Themen abhandelt:

Inhalt:

Zuordnung der Schwerpunkte zu den Testzyklen

Schrittweise Verfeinerung der Schwerpunkte

Ergänzende Planung von Phasen

Regelung von Zuständigkeiten

Zeiten:

Angabe von Beginn und Ende der einzelnen Testzyklen

Zuordnung von Terminen

Ressourcen:

Zuordnung der Aufgaben an Mitglieder des Testteams

Angabe des Arbeitsaufwands für die Aktivität

Belegungsplan für die Testinfrastruktur

Abhängigkeiten

Definition der Testreihenfolge zur minimierung von Redundanz

Externe Zulieferungen (z.B. Testdatenbanken, etc.)

Die frühzeitige Planung ergibt einen Zeitgewinn da schon vor Anlieferung der Applikation

zum Test einiges an Aktivitäten vorab erfolgen kann (z.B. Vorbereitung für

Testautomatisierung). Zudem kann bei Ressourcenknappheit dies rechtzeitig gemeldet

werden.

5.4. Organisation und Koordination von Teststufen

Es bestehen in der Regel folgende Test Organisationsformen:

Entwickler testet seine Software selber -> Vorteil, der Entwickler kann sein Werk gleich selber testen, Nachteil, die Entwickler sind keine Tester




Testgruppe in der Projektorganisation -> Vorteil, gute Kenntnisse des mitentwickelten Produktes und bessere Planbarkeit der Ressourcen, Nachteil, die Projektleitung beeinflusst die Tester zu stark

Testlabor/Testzentrum -> Vorteil, effektive Abläufe und hohe Professionalisierung, Nachteil, hoher Kommunikationsaufwand und hoher Know-How Transfer

Die Koordination der Testzyklen und Teststufen beinhaltet folgende Punkte

Definieren von Testende und Abnahmekritierien

Definieren von Abbruchkriterien und Wiederaufnahmebedingungen

Koordination der Teststrategie - Sequenziell arbeitende Teststufen, jeder Build durchläuft einen vollständigen Regressionstest - Parallel arbeitende Teststufen, ein Build durchläuft alle Teststufen gleichzeitig

Eingangstests und Freigabetests

5.5. Weitere Aspekte der Testplanung

Testdokumente in Konfigurationsmanagement verwalten

Definition der Testumgebung

Mitarbeiterprofile und Schulungsmassnahmen

5.6. Spezielle Testmanagementaufgaben

Testen von Multisystemen (z.B. B2B Plattformen wie PayPal,

Telekommunikationsnetzwerke, etc.) bedingt

stringentes Vorgehensmodell

frühe Qualitätssicherungsmassnahmen

flexible Integrationstestumgebungen

definierte Prozesse für das Konfigurationsmanagement

Test von sicherheitskritischen Systemen wird unterteilt in drei Stufen

Systeme mit grosser Komplexität und aufwender Technologie welche eine Beherrschung der Risiken fast unmöglich macht (Waffensysteme, Kernkraftwerke)

Systeme die aufgrund ihrer Komplexität, Technologie oder Zielsetzung kritisch sind, deren Einsatz aber unverzichtbar ist (Luftfahrt, Strassen- und Eisenbahn)

Systeme deren Komplexität und Technologie es möglich erscheinen lässt mit vertretbarem Aufwand die Risiken zu begrenzen (Überwachung von Maschinen, IT-Systeme)

Durch die konsequente Umsetzung der Testziele kann für diese Systeme die

Ausfallsicherheit enorm gesteigert werden.

Exploratives Testen, wird als reaktive Teststrategie bezeichnet. Kommt zum Zuge wenn

Es existieren keine oder nur wenige Dokumente

Die Dokumentation ist stark veraltet


ISTQB TESTMANAGERTeststeuerung


Dieses System basiert auf Intuition und Erfahrung der Tester, es lässt sich bei zeitlichen

Restriktionen gut einsetzen

Bei einer Testsitzung werden folgende Punkte durchgeführt

Testvorbereitung

Testdurchführung

Dokumentation und Auswertung

Am Ende führt der Testmanager mit dem Testteam eine Sitzung durch um die Auswertung

zu besprechen.

Die Abschlussbesprechung richtet sich nach dem PROOF Prinzip:

Past: Was passierte in der abgelaufenen Testeinheit

Results: Welche Ergebnisse wurden erzielt

Outlook: Was ist noch zu tun

Obstacles: Welche Hindernisse waren zu überwinden

Feelings: Wie ist die Einschätzung der Tester

6. Teststeuerung

6.1. Initiierung der Testaufgaben

Der definierte Plan (Testkonzept) muss aktiv gesteuert, resp. Initiiert werden, hierfür

existieren zwei Systeme

Feste Zuweisung der Testthemen an einzelne Mitarbeiter Vorteil: Der Tester kann sich tief in das Thema einarbeiten Nachteil: Es benötigt gut ausgebildete Mitarbeiter, Themen sind an bestimmte Personen gebunden

Testphasen-, rsp. Rolleinorientierter Einsatz der Testmitarbeiter Vorteil: Die Tester können flexibel eingesetzt werden. Nachteil: Die Tests müssen sehr detailert spezifiziert sein

6.2. Überwachung des Testfortschritts

Der Testfortschritt gegenüber dem Testplan muss jederzeit überwacht werden. Es sind

dabei Fragen zu drei Aufgabenkategorien zu beantworten

Wieviele Testfälle sind bereits spezifiziert, welche Risiken sind adressiert, gibt es Risiken die noch nicht adressiert sind?

Welche Tests sind automatisiert?

Welche und wieviele Tests (automatisiert und manuelle) sind gelaufen?

Testfortschritt ermitteln

Status der Fälle im Testplan


ISTQB TESTMANAGERTeststeuerung


Abgedeckter Testobjektumfang

Adressierte Produkterisiken

Vertrauen in die Güte des Produktes

Zahl der aufgedeckten Fehler

Der Testfortschritt sollte in kurzen Abständen erfolgen, meist wöchentlich, in „heissen“

Phasen sogar täglich.

6.3. Reagieren auf Testergebnisse

Folgende Korrekturmassnahmen können anhand der gewonnenen Erkenntnisse

vorgenommen werden

Verlagerung von Testfällen auf andere Mitarbeiter

Aufstocken von Ressourcen

Testfälle terminlich verschieben

Wie können die Testergebnisse, bzw. die Fehlerdaten zur Steuerung des Tests eingesetzt

werden

Wo einige Fehler sind, sind auch noch mehr

Wo keine Fehler sind fehlen Testfälle

Fehlertrendkurve zeit das Testende an

6.4. Reagieren auf veränderte Rahmenbedingungen

Falls sich grundlegende Rahmenbedingungen ändern muss das Testkonzept und damit die

weitere Vorgehensweise im Test angepasst werden

Es ist aber klar auf das erhöhte Projekt- und Produktrisiko hingewiesen werden.

6.5. Testendbewertung

Bei Ende des Tests stellen sich die Fragen

Wurde genug getestet?

Ist die Qualität des Testobjekts erreicht?

Wurden Fehler übersehen?

Das Dilemma ist folgendes

Wird der Test zu früh beendet sind evtl. noch Fehler vorhanden

Wird der Test zu spät beendet steigen die Kosten

Testendekritierien richten sich nach den Punkten

Beurteilung des erreichten Testfortschritts

Beurteilung der vorliegenden Testergebnisse


ISTQB TESTMANAGERBewertung und Verbesserung des Entwicklungs- und Testprozesses


Abschätzung des Restrisikos Wirtschaftliche Rahmenbedingungen

Es können pro Teststufe bestimmte Metriken angewendet werden

Komponententest, testobjektbasierte, strukturorientierte Metriken kombiniert mit einer Metrik zum Testumfang je Komponente

Integrationstest, in erster Linie strukturorientierte Metriken

System / Abnahmetest, testplan-, fehlerbasierte sowie anforderungsbasierte Metriken

6.6. Der Testbericht

Der Testbericht liefert die Bewertung der getesteten Software und ist nicht mit dem

Testprotokoll zu verwechseln welches Informationen zu einem Testlauf liefert.

Der Testbericht wird zum Ende eines Testzyklus erstellt.

Im Dokument sollten die unten aufgeführten Punkte enthalten sein

Kontext (Autor, Projekt, Testobjekt, etc)

Testfortschritt

Produktqualität

Ressourcen Massnahmen

Budget

Risiken

Weitere Planung

7. Bewertung und Verbesserung des Entwicklungs- und

Testprozesses

Ziel aller Entwicklungs- und Testprozesse ist

Projekte realistisch planen und Planung erfolgreich umsetzen

Transparenz über den Projektstand und –fortschritt zu erreichen

Erhöhung der Qualität der gelieferten Artefakte

Senkung der Kosten

Verkürzung der Entwicklungszeit

7.1. Allgemeingültige Verfahren und Vorgehensweisen

Eine grundlegende Herangehensweise für die Umsetzungen bei Entwicklungs- und

Testprozessen ist der Deming-Kreis, er setzt sich aus den Aktivitäten Plan, Do, Check und

Act zusammen (PDCA).

Eine Erweiterung des PDCA Kreises ist IMPROVE (Initiate, Measure, Prioritize, Redefine,

Operate, Validate, Evolve).




7.1.1. Total Quality Management (TQM)

Das TQM wird in der DIN Norm 8402 abgebildet.

Im Mittelpunkt steht die Kundenzufriedenheit, mit dem Begriff Total wird ein Umfassendes

Konzept angestrebt das alle Mitarbeiter über alle Hierarchiestufen, die Lieferanten und auch

die Kunden mit einbezieht.

TQM stellt keinen Plan oder detaillierte Handlungsanweisungen zur Verfügung, es wird

vielmehr eine Grundhaltung im Hinblick auf Qualitätsbewusstsein und wirtschaftliches

Handeln vermittelt

Die Prinzipien sind:

Kundenorientierung, nur umsetzen was dem Kunden nützt und was machbar ist

Prozessorientierung, die Erstellung erfolgt nach einem definierten Prozess

Primat der Qualität, die Qualität hat absoluten Vorrang, Fehler müssen unverzüglich geklärt werden.

Zuständigkeit aller Mitarbeiter, jeder Mitarbeiter ist für die Qualität verantwortlich

Internes Kunden-Lieferanten-Verhältnis, während der Entwicklung sind formale Abnahmen und Übergaben der Zwischenprodukte durchzuführen.

Kontinuierliche Verbesserung, kleine Schritte, nicht Grosse bringen den Erfolg

Stablisierung von Verbesserungen, Änderungen müssen rasch umgesetzt werden damit die gefundenen Fehler im Alltagsgeschäft nicht wieder in Vergessenheit geraten.

Rationale Entscheidungen, Entscheidungen und Änderungen sind explizit und auf Faktenbasis zu begründen

7.1.2. Kaizen

Der Begriff stammt aus dem Japanischen, Kai (Veränderung) und Zen (zum Besseren). Die

Ausgangsüberlegung ist folgende: Ein System oder Prozess ist ab seiner Einsetzung dem

Verfall preisgegeben, wenn nicht ständig Erneuerungen und/oder Verbesserungen erfolgen.

Es wird wie bei TQM ein Ganzheitlicher Ansatz mit allen Beteiligten angestrebt.

Grundpfeiler von Kaizen sind:

Intensive Nutzung und Perfektionierung des betrieblichen Vorschlagwesens

Aussprechung der Anerkennung für das Bestreben nach Verbesserung

Etablierte Diskussionszirkel zu Mängeln und Verbesserungsvorschlägen im kleinen Kreis

Just in Time Produktion

5 S-Prozess zur Verbesserung der Arbeitsplätze

Total Productive Maintenance zur Wartung und Pflege aller Produktionsmittel Der 5 S-Prozess hat das Ziel saubere, sichere und standardisierte Arbeitsplätze zu

etablieren und basiert auf 5 japanischen Wörtern welche die Begriffe Sauberkeit,

Ordentlichkeit, Reinlichkeit, Standardisierung und Disziplin ausdrücken.




7.1.3. Six Sigma

Ist ebenfalls ein Vorgehen oder Rahmenwerk zur Prozessverbesserung. Der Begriff Sigma

kommt aus der Statistik und bezeichnet die Standardabweichung einer statistischen

Verteilung.

Schlüsselaussagen und Konzepte von Six Sigma sind:

Qualität entscheidet

Mängel vermeiden

Reife des Prozesses gewährleisten

Schwankungen gering halten

Beständiger Arbeitsablauf

Ausrichtung auf Six Sigma

Das Vorgehen bei Six Sigma beruht auf den Methoden

DMAIC (define measure, analyse, improve, control), wird bei bestehenden Prozessen angewendet

DMADV (define, measure, analyse, design, verify), wird bei der Softwareentwicklung angewendet

DFSS (design for six sigma), neue Prozesse genügen dem Six Sigma Anspruch

Das Ausbildungsprogram gliedert sich in folgende Bereiche

Master Black Belt zuständig für Projektberatung und Schulung

Black Belt Leiter von grossen Projekten mit hohen Ansprüchen

Green Belt Leiter von kleinen Projekten

Yellow Belt Six Sigma Grundkenntnisse vorhanden

7.2. Verbesserung des Softwareentwicklungsprozesses

Es bestehen zwei Gruppen von Modellen zur Bewertung von

Softwareentwicklungsprozessen:

Die erste Gruppe definiert Eigenschaften für die einzelnen Prozesse und nennt Kriterien um die Bewertung durchzuführen. Diese Gruppe wird Prozessreferenzmodelle genannt.

Die zweite Gruppe enthält konkrete Hinweise zur Umsetzung von Prozessverbesserungen, rsp. zur Gestaltung von Prozessen. Dies Gruppe wird Inhaltsreferenzmodelle genannt.

7.2.1. Capability Maturity Model Integration (CMMI)

CMMI wird in 5 Reifgradstufen unterteilt welche in der nachfolgenden Grafik dargestellt sind.




Stufe 1: Initial, Prozesse sind nicht oder ungenügend definiert, Entwicklung läuft chaotisch und auf Zuruf.

Stufe 2: Gemanagt, die wesentlichen Prozesse des Managements sind etabliert und werden angewendet

Stufe 3: Definiert, Organisationsweite, einheitliche Prozesse sind definiert

Stufe 4: Quantitativ gemanagt, Entscheidungen über Verbesserungen werden auf Grundlage von Kennzahlen getroffen.

Stufe 5: Optimierend, Prozessverbesserungen finden systematisch und kontinuierlich statt.

CMMI kennt zwei Darstellungsarten:

Stufenförmige Darstellung (siehe Grafik oben)

Kontinuierliche Darstellung (siehe Grafik unten)

Testmanager und CMMI

Der Testmanager finde keine sehr detaillierten Beschreibungen oder Hilfestellungen für

seine Aufgaben, da Informationen nicht über die Kenntnisse des fundamentalen

Testprozesses hinausgehen.

7.2.2. ISO/IEC 15504 (SPICE)

CMMI diente SPICE als Grundlage, die Ansätze sind daher ähnlich.




Die Norm bildet den Rahmen für eine einheitliche Bewertung der Leistungsfähigkeit einer

Organisationseinheit durch Bewertung von gelebten Prozessen, sie umfasst

Prozessbewertung, Prozessverbesserung und Leistungsbestimmung.

Die Fähigkeitsstufen sind:

Ist unvollständig (Stufe 0)

Wird durchgeführt (Stufe 1)

Wird gemanaged (Stufe 2)

Ist etabliert (Stufe 3)

Ist vorhersagbar (Stufe 4)

Ist selbstoptimierend (Stufe 5)

Testmanager und SPICE

Es finden sich keine detailierten Angaben über Aufgabenbeschreibungen. Hilfreich sind

einzig die Angaben zu den erforderlichen Ergebnissen.

7.3. Bewertung von Testprozessen

Die nach dem Prozessassessment gesammelten Informationen über die bestehenden

Prozesse in einer Organisation können mittels den zwei Gruppen angegangen werden:

TMM und TPI bieten konkrete Hinweise zur Umsetzung von Prozessverbesserungen an

STEP und CTP bieten Informationen an wo sich Investitionen in die Testprozessverbesserung lohnen. Sie geben keine konkreten Hinweise für die Umsetzung, die Organisation muss den Weg zur Verbesserung selber finden.

7.3.1. Testing Maturity Model (TMM)

TMM legt sein Augenmerk insbesondere auf den Test als Prozess der evaluiert und

verbessert wird.

TMM definiert an CMM fünf Reifegradstufen:

1. Initial




2. Phasendefinition 3. Integration 4. Management und Metriken 5. Optimierung

Pro Stufe kommt ein hierarchisches Rahmenwerk zum Einsatz welches aus den in der

nachfolgenden Grafik enthaltenen Teilen:

Reifeziele

Reifezielteile

Aktivitäten, Aufgaben und Verantwortlichkeiten besteht.

TMM ist als Ergänzung zu CMMI gedacht, die Reifegradstufen beider Modelle

korrespondieren weitgehend miteinander.

TMM Assessment Modell

Dieses Modell soll Organisationen helfen ihren Testprozess zu beurteilen und zu

verbessern.

Hierfür werden mehrere Inputdokumente als Grundlage für die Bewertung benötigt. Neben

dem TMM fliessen zudem noch folgende Komponenten ein:

Fragebogen

Ablauf des Assessments

Teamschulung und Auswahlkriterien




7.3.2. Test Process Improvement (TPI)

Das Bewertungsmodell ermöglicht die Bestimmung der Reife des Testprozesses in einer

Organisation und unterstützt die schrittweise Prozessverbesserung.

TPI definiert 20 Kerngebiete, durchschnittlich existieren 3 Ebenen pro Kerngebiet. Die

Stärken und Schwächen eines Testprozesses werden mithilfe von sogenannten

Kontrollpunkten ermittelt.

Für jede Ebene sind Optimierungsvorschläge zur Erreichung der nächsten Ebene

beschrieben.

Es existieren die Kerngebiete:

Teststrategie

Einsatz des Phasenmodells

Zeitpunkt der Beteiligung

Kostenvoranschlag und Planung

Testspezifikationstechniken

Statische Testtechniken

Metriken

Testwerkzeuge

Testumgebung

Testarbeitsplatz

Engagement und Motivation

Testfunktionen und Ausbildung

Reichweite der Methodik

Kommunikation

Berichterstattung

Dokumentation und Abweichung

Testwaremanagement

Testprozessmanagement

Prüfungen

Low-Level-Tests

In der nachfolgenden Grafik ist die Auswertung der Analyse ersichtlich




Die Skala 1-13 ist wie folgt aufgeteilt:

1-5 Beherrschbar

6-10 Effizient

11-13 Optimierend

In den Kreuzungen zwischen Skala und Kerngebiet wird die erreichte Ebene mittels den

Buchstaben von A bis D markiert, wobei A die unterste Ebene darstellt.

7.3.3. Systematic Test und Evaluation Process (STEP)

Im Gegensatz zu TMM und TPI bietet STEP kein konkretes Referenzmodell an, es werden

wie bei CTP einzelnen Massnahmen und Vorgehensweisen vorgestellt und erörtert. STEP

ist ein Inhaltsreferenzmodell.

Grundlage von STEP sind die IEEE-Standards zum Unit Test und zur Testdokumentation.

STEP beschreibt alle Aktivitäten der Evaluation bei Softwareprojekten, dazu gehören

Analyse, Review und Test.

Der Testprozess nach STEP besteht aus den Phasen:

Planen (Ermittlung der Risiken und Auswahl der Strategie)

Analyse (Testziele, -bedingungen und –anforderungen festlegen)

Entwurf (Spezifikation der Testfälle)

Implementierung (Konstruktion und Bereitstellung der Testprozeduren und Testfälle)

Ausführung (Lauf und ggf. wiederholter Lauf der Testfälle)

Wartung (Sicherung und Aktualisierung der Tests nach Änderungen)

Nach STEP sind für jede Stufe die Planung der Strategie, die Bereitstellung der Testware

sowie die Messung des Verhaltens bzw. der Ergebnisse durchzuführen.

7.3.4. Critical Testing Process (CTP)

Bei CTP werden nur die „kritischen“ Aspekte des Testens betrachtet, welche für den

Testerfolg massgebend sind.

Sind diese erkannt und etabliert werden sie auch gut ausgeführt, zudem unterstützen sie

das Testteam da Arbeitsabläufe erfolgreicher durchgeführt werden können.




Das Vorgehen basiert auf Checklisten und Fragen.

CTP gehört zur Gruppe der Inhaltsreferenzmodelle.

Das Modell kennt zwölf Aspekte, zu jedem ist ein Set vordefinierter Fragen zu beantworten.

Die Aspekte werden in vier Gruppen unterteilt.

Die nachfolgende Auflistung zeigt die Gruppen sowie die zugeteilten Aspekte:

Planen - Umfeld berücksichtigen - Risiken managen - Testaufwand schätzen - Tests planen

Vorbereiten - Testteam zusammenstellen - Testsystem erstellen

Durchführen - Testreleases managen - Tests durchführen

Vervollständigen - Abweichungen managen - Ergebnisse berichten - Änderungen managen

7.3.5. Vergleich der Bewertungs- und Prozessmodelle

Die vier Prozessmodells sind ausschliesslich auf den Testprozess fokussiert.

TMM ist auf der Grundlage von CMM erstellt worden, TPI mehr auf CMMI. Diese beiden

Modelle sind für den Testmanager von grosser Bedeutung da sie helfen den Testprozess zu

analysieren, zudem liefern sie konkrete Tipps zur Verbesserung.

STEP und CTP sind Beschreibungen von Vorgehensweisen beim Testprozess und liefern

keine direkten Bewertungen oder Einstufungen. Trotzdem sind sie als wertvolle Quellen für

„Best Practices“ zu sehen und helfen den Testprozess in Relation zu den Modellen zu

vergleichen und zu vervollkommnen.

7.4. Audit und Assessment

Audit ist eine systematische und unabhängige Untersuchung zur Bewertung von

Softwareprodukten und Entwicklungsprozessen, um Konformität mit Standards, Richtlinien,

Spezifikationen und/oder Prozessen zu bestimmen.

Ein Audit basiert auf objektiven Kriterien, Grundlage sind Dokumente die

Den Inhalt der zu erstellenden Produkte festlegen

Den Prozess der Erstellung der Produkte beschreiben

Spezifizieren wie Standards und Richtlinien gemessen werden können

Audits dauern in der Regel wenige Tage und werden von ca. 2-4 Personen durchgeführt.

Ziel des Audits ist es Schwachstellen aufzuzeigen.




Assessments sind ähnlich wie mehrtägige Audits jedoch mit grösseren Teams (ca. 3-5

Personen) und erweitertem Vorgehen.

Bei einem Assessment werden die betrieblichen Abläufe mit den Anforderungen eines

Bewertungsmodells wie z.B. CMMI, verglichen.

Es werden direkte Artefakte wie Richtlinien, Arbeitsanweisungen und Prozessmodelle, sowie

indirekte Artefakte wie Protokolle, Berichte und ausgefüllte Templates analysiert. Zudem

werden die aktiven Prozesse mittels Interviews und via „über die Schulter schauen“ geprüft.

7.4.1. Durchführung eines internen Audits oder Assessments

Die wesentlichen Schritte zur Vorbereitung eines Assessments sind:

Sponsor identifizieren

Zweck des Assessments identifizieren

Umgang festlegen

Vorgehensweise und Modell auswählen

Randbedingungen und Einschränkungen identifizieren

Kontrolle über die Assessmentergebnisse und Vertraulichkeit

Beiteiligte Personen und Rollen identifizieren

Die Vorbereitung des Assessments ist der wichtigste Schritt.

Basierend auf den gewonnenen Informationen kann mit der Planung begonnen werden. Es

sind folgende Aspekte zu beachten:

Risiken die zum Scheitern, oder negativer Beeinträchtigung der Ergebnisse führen können

Organisation der Interviews, Termin- und Ressourcenplanng

Bereitstellung der Infrastrukturen und Dokumente

Nach Abschluss der Planung findet der eigentliche Assessment statt (Interviews, sichten der

Dokumente, etc.)

Nach der Durchführung und Protokollierung erfolgt die Validierung der Ergebnisse.

7.4.2. Vorbereitung auf ein Audit oder Assessment durch Externe

Es basiert auf den gleichen Regeln wie ein internes Assessment, meistens wird es

angewendet um die Eignung eines Lieferanten oder interne Prozesse zu prüfen.

Die externen Assessoren müssen grösste Neutralität wahren, sich klar über den Input sowie

die Lieferobjekte sein.


ISTQB TESTMANAGERAbweichungsmanagement


8. Abweichungsmanagement

8.1. Fehler und Fehlerfindung

Die Abweichung beschreibt den Unterschied zwischen dem erwarteten und tatsächlichem

Verhalten einer Software.

Abweichungen entstehen aus der Kette

Fehlhandlung

Fehlerzustand

Fehlerwirkung

8.2. Dokumentation von Abweichungen

Die Personen die Abweichungen aufdecken sind in der Regel andere welche die

Abweichungen analysieren und beheben, somit sind die Abweichungen zu dokumentieren.

- Der Sachverhalt muss eine einfache und eindeutige Reproduktion der Fehlerwirkung

ermöglichen:

Testablauf und Eingabeparameter beschreiben

Meldungen sollen knapp und klar formuliert werden

Keine Kombinationen aus mehreren Abweichungen

Dokumentation der Testumgebung und Release

- Die Abweichungen zueinander müssen priorisiert werden können

- Jeder Abweichung muss ein Status zugewiesen sein

- Datum und Zeit der Abweichung muss beschrieben sein

8.3. Bearbeitung von Abweichungen

Die Bearbeitung einer Abweichung wird durch mehrere Rollen abgedeckt die sich oft

überschneiden:

Tester – meldet Abweichungen und führt den Fehlernachtest durch

Testmanager – leitet Testgruppe und leitet Abweichungsmanagement

Entwickler – analysiert Abweichungen und behebt Fehlerzustände

Entwicklungsleiter – leitet das Entwicklungsprojekt, schätzt Aufwendungen für Fixes

Produktmanager – leitet das Entwicklungsprojekt, genehmigt Änderungswünsche und legt Priorisierung der Korrekturen fest

Kunde – bewertet neu auftretende Abweichungen hinsichtlich Relevanz, meldet selber auch Abweichungen (werden oft später als Changes erkannt)

Change Control Board – entscheidet über Priorisierung von Fehlerbehebungen und Änderungswünschen


ISTQB TESTMANAGERAbweichungsmanagement


Zur Bearbeitung von Abweichungen wird oft ein Prozessmodell erstellt, nachfolgend ein

Beispiel:

Meldungsvorlage, bzw. –ablage und Managementprozess werden am Besten in einer

Datenbank, einem sogenannten Defect Management System, abgebildet.

Dieses System vereinfacht die Bearbeitung der Abweichungen da

Benutzer Rollen für die Bearbeitung der Abweichungen zugewiesen werden können

Statuswechsel verfolgt werden können

Schnittstellen zu anderen Werkzeugen implementiert werden können (z.B. zum Requirement System)

Reporting Funktionen eingebaut werden können

In Grösseren Testprojekten empfiehlt sich ein Defect Management System in kleineren kann

auch ein Excelsheet zum Einsatz kommen.

8.4. Standardisierte Klassifikation von Abweichungen nach IEEE

1044/1044.1

Um eine gemeinsame Basis für historisch gewachsene Heterogenität von

Abweichungsprozessen zu erstellen wurde ein Standard definiert.

Dieser beschreibt die Klassifizierung von Abweichungen, die Dokumentation der

Eigenschaften einer Abweichung und den zugehörigen Prozess.

Übersicht des Klassifikationsprozesses:

Erkennung (recognition)

Analyse (investigation)

Behebung (action)

Abschluss (disposition)

Jeder dieser vier Schritte enthält drei nebenläufige Tätigkeiten:


ISTQB TESTMANAGERRisikomanagement und risikoorientierter Test


Dokumentieren (recording)

Klassifizieren (classifying)

Auswirkungen bestimmen (identifying impacts)

Das Ziel dieser Tätigkeiten ist die klare Klassifizierung. Nicht die Schwere oder Auswirkung

einer Abweichung ist gefragt, sondern die Umstände der Erkennung und die notwendigen

Massnahmen zur Behebung.

Da der Standard sehr umfassend ist wird er in vielen Projekten den Bedürfnissen angepasst

und ist somit gestrafft.

9. Risikomanagement und risikoorientierter Test

9.1. Einführung

Die Höhe eines Risikos ergibt sich aus der Wahrscheinlichkeit des Problemeintritts und dem

damit verbundenen Schaden.

Das Risikomanagement befasst sich mit den Themen:

Systematische Identifikation

Analyse

Bewertung

Steuerung

Bewältigung

Überwachung und Kommunikation von Risiken.

Ziel des Risikomanagements ist es, diejenigen Risiken zu identifizieren deren Eintreten den

Projekterfolg gefährden oder zu einem grob Mangelhaften Produkt führen, sowie

Massnahmen zu definieren die eine Wahrscheinlichkeit eines solchen Szenarios verhindern,

oder mindestens vermindern.

Zum Risikomanagement gehören folgende wichtige Beteiligten und ihre

Verantwortlichkeiten:

Auftraggeber – fordert Projektrisikomanagement und liefert Informationen zu den Risiken des Produkteumfelds

Leiter Auftragnehmer – fördert Projektrisikomanagement

Projektmanager – berücksichtigt im Projektbudget die Kosten der risikomindernden Massnahmen, wirkt beim Risikomanagement mit

Testmanager – wirkt am Risikomanagement mit, optimiert die Teststrategie

Entwickler/Tester – liefern Informationen zu den Projekt- und Produkterisiken




9.2. Ermittlung des Kontextes

9.3. Risikoidentifikation

9.3.1. Grobgranulare Risikokategorisierung

Eine grobgranulare Risikokategorisierung wird in externe und strategische Risiken aufgeteilt,

sowie in Projekt- und Produkterisiken.

Externe Risiken (sind nicht beeinflussbar und nicht vorhersehbar):

Naturereignisse

Politische oder gesellschaftliche Veränderungen

Makroökonomische Veränderungen

Neue Märkte

Technische Veränderungen

Änderung des Kundenverhaltens

Strategische Risiken (sind nicht beeinflussbar aber vorhersehbar):

Wechselnde Marktanteile

Änderungen der Organisationsstruktur

Ressourcenknappheit

Investitionsänderungen

Kommunikationshemmnisse

Projektrisiken (relativ gut beeinflussbar und vorhersehbar):

Probleme in der Logistik




Probleme im Vertrieb

Mitarbeiterfluktuationen

Fehlendes Wissen

Teamkonflikte

Zu optimistische Zeitplanung

Aggressive Preispolitik

Kommunikationsprobleme durch verteilte Entwicklung

Neue Entwicklungsverfahren

Produktrisiken (beeinflussbar und gut vorhersehbar):

Funktionale Aspekte die besonders kritische Funktionen oder Geschäftsprozesse treffen

Nicht funktionale Aspekte (hohe Anzahl Fehlerzustände im Code, schlechte Benutzbarkeit, schlechte Performance)

9.3.2. Techniken und Hilfsmittel

Zur Identifikation der Risiken sind folgende Techniken und Hilfsmittel anwendbar:

Experteninterviews und Fragebögen

Unabhängige Einschätzung (Audits, Assessments)

Durchführung von Risikoworkshops (FMEA, FMECA, FTA)

Risiko Brainstorming

Verwendung von Risikoformularen

Erfahrung aus abgeschlossenen Projekten

9.4. Risikoanalyse und –einstufung

Bei der Risikoanalyse werden die identifizierten Risiken abschliessend katalogisiert und

quantitativ einer Risikostufe zugeteilt.

Ein weiteres Ergebniss ist ein ausführliches Risikoinventar in dem alle Risiken kategorisiert,

klassifiziert, erläutert und mit einer Eintrittswahrscheinlichkeit versehen sind.

9.4.1. Feingranulare Risikokategorisierung

Produktrisiken und spezielle Projektrisiken werden erst bei der Risikoanalyse kategorisiert.

Produktrisiken führen bei den betroffenen zu direkten und indirekten Fehlerkosten.

9.4.2. Quantitative und qualitative Risikoeinstufung

Quantitative Einstufung:

Basiert auf statistischem Datenmaterial

Basiert auf Wahrscheinlichkeitsrechnung

Systemanalysen

Fehlerzustandsbaumanalysen




Störfallablaufanalysen

Qualitative Einstufung:

Szenariobasierte Analysen

ABC Analysen

Scoring Modelle

Risikomatrizen

Berechnung des Risikos: Risiko = Wahrscheinlichkeit * Schadenshöhe

Die Wahrscheinlichkeit wird zwischen den Werten 0% (nie) und 100% (sicher) festgelegt. Die Eintrittswahrscheinlichkeit wird durch technische Faktoren bestimmt -> technical risks.

Die Schadenshöhe wird als Geldwert (wenn möglich) angegeben, sie wird meistens durch geschäftliche Faktoren beeinflusst -> business risks

Zur Beurteilung von Risiken wird der

MPL (maximum possible lost)

PML (probable maximum loss) ermittelt.

9.4.3. Risikoeintrittsindikatoren

Zu jedem identifizierten Risiko sind Indikatoren (triggers) anzugeben die den

bevorstehenden Eintritt ankündigen.

Zu jedem Indikator gehören:

Metriken

Berechnungsvorschrift für den Gesamtwert des Indikators

Schwellwert

9.4.4. Risikoinventar

Die Erkenntnisse der Risikoanalyse fliessen in das Risikoinventar (Risikoregister,

Risikoportfolio, Risikoprofil)

In komprimierter Form sind alle Risiken in einer Grafik abgebildet, wie z.B. das nachfolgende

Diagramm veranschaulicht.




R1 & R7 weit ausserhalb der Schwellwerte

R3 bis R6 knapp unterhalb der Schwellwerte

R2 kurz vor dem Eintritt

9.5. Risikosteuerung und –beherrschung

Die Risikosteuerung und –beherrschung umfasst Aktivitäten die als Reaktion auf die

identifizierten und analysierten Risiken ergriffen werden.

Mögliche Reaktionen:

Ignoranz, nichts tun und abwarten ob das Problem eintritt.

Risikominderung, ausgliedern von Unternehmensfunktionen, erstellen von Notfallplänen

Schadensminderung, Übertrag von Risiken an andere, z.B. erstellen einer Versicherung.

Absolute Risikovermeidung, Aufgabe des Projektes

9.6. Risikoüberprüfung und –überwachung

Lückenlose Überwachung der Risiken muss über die gesamte Projektdauer erfolgen. Dies

kann z.B. bei Meilensteinen des Projektes durchgeführt werden.

9.7. Risikoorientierte Testkonzepterstellung und Testpriorisierung

Man begegnet den Risiken auf drei Arten:

Zielgerichtet testen

Priorisiert testen

Im Testbericht die Restrisiken beziffern

Die Produktrisiken bestimmen die Teststrategie.




Die Projektrisiken bestimmen den Testplan.

Ein einfaches tabellarisches Verfahren zur risikobasierten Testpriorisierung (nach Schäfer):

Ermitteln der allgemeinen Risikofaktoren, dann

Gruppieren in je 3 Schadens- und Testrisikofaktoren.

Die nachfolgende Tabelle zeigt ein Beispiel:

Testen kann dazu verwendet werden um Risiken zu mindern.

9.8. Quantitative Fehlzustandsanalysen

Die Fehlerzustandsanalyse ist eine systematische Vorgehensweise für die

Risikoidentifikation und die Analyse möglicher Fehlerzustände/Fehlerwirkungen sowie die

Klassifizierung der Kritikalität.

9.8.1. Fehlzustandsart- und –auswirkungsanalyse (FMEA)

FMEA ist eine induktive Methode der Durchführung einer qualitativen Systemzuverlässigkeit-

oder Sicherheitsanalyse.

Induktiv bedeutet das die Analyse der Systemkomponenten von niederen Ebenen bis zum

Gesamtsystem erfolgt.

Die FMEA ist nicht anwendbar auf Situationen mit mehrfachen oder voneinander

abhängigen Fehlerwirkungen.

Vorgehen bei FMEA:

Systemstruktur analysieren und Anforderungen den Strukturelementen zuordnen.

Pro Betrachtungseinheit (System, Teilsystem, Komponente) ordnet man Risikofaktoren zu

Pro Risikofaktor wird die Eintrittswahrscheinlichkeit bestimmt

Danach werden Auswirkungen auf Projektplanung untersucht

Massnahmen zur Vermeidung bestimmen




Am Ende werden die Ergebnisse Dokumentiert

9.8.2. Fehlerzustandsart-, Auswirkungs- und Ausfallbedeutungsanalyse (FMECA)

FMECA ist die Erweiterung der FMEA, sie betrachtet zusätzlich die Wahrscheinlichkeit der

Entdeckung, also die quantitative Bewertung der identifizierten Risikoeintrittsindikatoren, der

eingesetzten Testtechniken und der Zuverlässigkeit der Softwarefunktionen.

9.8.3. Fehlerzustandsbaumanalyse (FTA)

Bei der FTA werden mittels einer Grafik die Ursachen und Wirkungszusammenhänge

aufgezeigt.

Im Gegensatz zur FMEA und FMECA wird bei der Analyse vom Gesamtsystem zu den

einzelnen Komponenten vorgegangen.

Ziele der FTA:

Aufzeigen von Ursachen

Ermittlung von Fehlerarten

Berechnung Eintrittswahrscheinlichkeit

Analyse von Entwurfsalternativen

Berechnung von Verfügbarkeit

Vorgehen bei der FTA:

Definition der Untersuchungsziele

Analyse der Konstruktion

Festlegung der Hauptereignisse

Konstruktion eines Fehlzustandsbaums

Analyse des Fehlzustandsbaums

Bericht über die Ereignisse der Untersuchung

Bewertung möglicher Verbesserungen und Risikominderungen


ISTQB TESTMANAGERMitarbeiterqualifikation


9.8.4. Risikobasierte Testaufwandoptimierung

10. Mitarbeiterqualifikation

10.1. Individuelle Fähigkeiten

Der optimale Testteammitarbeiter

Besitzt profunde IT Kenntnisse

Besitzt Anwenderwissen

Ist qualifizierter Tester

Hat hohe soziale Kompetenz

In der Praxis ist es aber oft so das nur eine Fähigkeit wirklich ausgeprägt ist.

Der Mix im Team macht es aus.

10.2. Fachliche Teamrollen

Folgende Rollen im Testteam sind vorhanden:

Testmanager: - Leitet das Testteam - Erstellt Testplan - Rapportiert an Projektleiter - Steuert den Testprozess - kennt Qualitätsmanagement




- hat Personalführungserfahrung - Kennt Normen und Standards - Kennt Testprozesse

Testdesigner - Ist verantwortlich für die Testspezifikationen - Wählt die Testmethoden aus - Definiert die Testumgebung - hat Softwareengineering Wissen - erstellt Testfälle und Testdaten - hat praktische Erfahrung als Tester

Testautomatisierer - Ist der Programmierer des Testteams - hat profunde Kenntnisse der im Testteam eingesetzten Tools - Entwickelt Testframeworks zu Testwerkzeugen

Testadministrator - macht Installation, Betrieb und Wartung der Testumgebung - hat Sysadmin Know-How - löst Konfigurationsprobleme

Tester - Führt Tests durch - Erstellt Abweichungs-, bzw. Fehlerbericht - arbeitet systematisch - ist kreativ - formuliert Fehlerwirkungen kurz und prägnant

Spezialisten - Lasttestspezialist, DB-spezialist, Netzwerkspezialist, etc.




10.3. Soziale Teamrollen

10.4. Faktor Kommunikation

Es gibt Teamexterne Kommunikation zwischen Tester und Entwickler, sowie Testern und

dem Projektmanagement, sowie Teaminterne Kommunikation welche vor allem

Teammeetings beinhaltet.

10.5. Faktor Motivation

Massnahmen welche die Motivation sicherstellen:

Realistische Planung vornehmen

Sorgen für Managementunterstützung

Adäquate Arbeitsumgebung

Leistungen des Testteams Unternehmensintern verkaufen

10.6. Ethik Kodex

Das ISTQB hat folgenden Ethik Kodex erstellt:

Öffentlichkeit, verhält sich mit dem öffentlichen Interesse übereinstimmend

Kunde und Arbeitgeber, wahrt die Interessen des Kunden und Arbeitgebers


ISTQB TESTMANAGERTestmetriken


Produkt, erfüllt die fachlichen Anforderungen

Urteilsvermögen, unabhängige Beurteilung wahren

Management, positive Einstellung zum Testmanagement

Berufsbild, Integrität zum Berufsbild

Kollegen, hilfsbereit, koorperativ und fair gegenüber Kollegen verhalten

Selbst, bildet sich weiter, orientiert sich nach diesen Richtlinien

11. Testmetriken

11.1. Einführung

Messen ist eine zentrale Tätigkeit des Testmanagements und baut auf soliden theoretischen

Grundlagen auf.

Testmetriken erlauben quantitative Aussagen bezüglich der Produktequalität, des aktuellen

Projektstands und der Reife des Entwicklungs- und Testprozesses.

Es bestehen

Testfallbasierte

Testbasis/Testobjektbasierte

Fehlerbasierte

Kosten/Aufwandbasierte Metriken

11.2. Etwas Messtheorie

Messungen können sich unmittelbar auf das Messobjekt beziehen, man spricht von einer

direkten Messung.

Von indirekten Messungen spricht man wenn nicht die eigentlich intressierende Eigenschaft

gemessen wird, sondern eine oder mehrere Punkte von denen man annimmt das sie einen

bestimmten Bezug zur interessierenden Eigenschaft haben.

Allgemein bildet eine Messung bestimmte Eigenschaften von Objekten in einem formalen

Relationensystem ab.

11.3. Definition und Auswahl von Metriken

Die Faktor-Kriterien-Metriken Methode (FCM) liegt vielen modernen Qualitätsmodellen

zugrunde.

Diese Methode unterscheidet zwischen internen und externen Metriken:

Interne, messen das Produkt an sich

Externe, messen die bei der Benutzung des Produktes beobachteten Eigenschaften

Vorgehen um die Metriken zu erhalten:




Ziele vorgeben

Anschliessen in einem Workshop die Ziele mit der Zielerreichung vergleichen

11.4. Darstellung von Messwerten

Beliebt sind Balken und Säulendiagramme zur Darstellung von einem oder mehrerer

Messobjekte.

Zur Abbildung einer Gesamtmenge sind Tortendiagramme zu verwenden.

Kummulativdiagramme sind zur Darstellung von zeitlichen Abläufen zu verwenden.

Kiviatdiagramme stellen die Werte vieler Metriken übersichtlich dar.

11.5. Einzelne Testmetriken

11.5.1. Testfallbasierte Metriken

Testfallbasierte Metriken fokussieren auf die Menge der Testfälle und ihre jeweiligen

Zustände, sie dienen zur Kontrolle des Fortschritts der Testaktivitäten.

Beispiele für testfallbasierte Metriken mit Absolutskala:

Anzahl geplanter Testfälle

Anzahl spezifizierter Testfälle

Anzahl Zeilen der Testskripte

Etc.

Beispiele für testfallbasierte Metriken mit Ratioskala:

Anzahl Testfälle mit Prio 1 / Anzahl geplanter Testfälle

Anzahl spezifizierter Testfälle / Anzahl geplanter Testfälle

Etc.

11.5.2. Testbasis- und testobjektbasierte Metriken

Durch Überdeckungsmetriken werden die zeitliche Entwicklung und die resultierenden

Auswirkungen auf den Zeitplan, die Ressourcen und die Aufgaben ermittelt.

Beispiele für Testobjektbasierte Metriken während des Integrationstests:

Prozentsatz getesteter Schnittstellen

Prozentsatz getesteter Schnittstellenverwendungen (Aufrufe von Operationen, bzw. Verwendung von Variablen der Schnittstellen)

Prozentsatz getesteter Schnittstellenparameter

Beispiele für Testobjektbasierte Metriken während des System- und Abnahmetests:

Anzahl getesteter Funkionen / Anzahl spezifizierter Funktionen

Anzahl getesteter Dialoge / Anzahl realisierter Dialoge




Anzahl durchgeführter Testfälle / Anzahl spezifizierter Testfälle

Etc.

11.5.3. Fehlerbasierte Metriken

Fehlerbasierte Metriken geben Auskunft zur Produktqualität, sie basiert auf der Auswertung

von gefundenen Fehlerwirkungen und Fehlerzustände.

Es werden folgende fehlerbasierte Metriken erhoben:

Fehlerdichte

Fehlerverteilung

Fehlerrate

Mittlere Zeitdauer bis zum Ausfall

Mittlere Betriebsdauer zwischen Ausfällen

Fehlerwirkungsankunftrate

Fehlerzustandsverweildauer

Indirekte fehlerbasierte Testmetriken erlauben Rückschlüsse auf Testeffektivität und

Testeffizienz.

11.5.4. Kosten und aufwandsbasierte Metriken

Sie geben den Rahmen der finanziellen, personellen und zeitlichen Möglichkeiten an und

lassen sich für die Planung zukünftiger Testprojekte und zur Optimierung des Testprozesses

verwenden.

Beispiele von aufwandsbasierten Metriken mit Absolutskala:

Anzahl Personentage für die einzelnen Phasen

Anzahl Personentage für Reviews

Anzahl Personentage für die manuelle Testdurchführung

Etc

Beispiele für die Produktivität zeigen diese Metriken mittels Ratioskala:

Anzahl gefundener Defekte pro Review-Personenstunde

Anzahl gefundener Fehlerwirkungen pro Test-Personenstunde

Anzahl erstellter Testfälle pro Personenstunde

Anzahl durchgeführter Testfälle pro Personenstunde

Etc

11.5.5. Beurteilung der Testeffektivität

Grundidee der Metrik zur Testeffektivität ist, dass die Fehlerrate lediglich die Anzahl

aufgedeckter und gewichteter Fehlerwirkungen pro Testfall angibt, aber keine Aussage über

die durch die Testfälle abgedeckten, bzw. nicht abgedeckten Teile der Software gibt.

Fehlerentdeckungsgrad (FEG) = Anzahl gew. Fehlerwirkungen im Test / Anzahl gew.

Fehlerwirkungen gesamt


ISTQB TESTMANAGERWerkzeuge zur Unterstützung des Testprozesses


11.6. Restfehlerabschätzung und Zuverlässigkeit

Die Zuverlässigkeit kann auf folgende Arten ermittelt werden:

Erfahrungsbasierte Abschätzung der Restfehlerwahrscheinlichkeit

Statistische Analyse der Fehlerdaten und Zuverlässigkeits-Wachstumsmodelle

11.6.1. Restfehlerwahrscheinlichkeit

Es gibt drei Möglichkeiten den Testprozess anhand der beobachteten Anzahl der

aufgedeckten Fehler zu bewerten:

Vor Testbeginn wird eine vermutlich vorhandene Anzahl Fehlerwirkungen geschätzt von denen ein bestimmter Prozentsatz beim Test aufzudecken ist

Es wird die tatsächliche Fehleraufdeckungsrate beobachtet

Es werden künstliche Fehlerzustände in das Programm eingefügt von denen ein bestimmter Anteil im Test zu Fehlerwirkugen führt

Anhand dieser Zahlen wir die Restfehleranzahl des Systems ermittelt

Anschliessend wird Effektivität des zukünftigen Testens (in Prozent der aufgedeckten

Fehlerwirkungen) für jede Teststufe geschätzt.

Daraus resultiert die folgende Formel:

Vorgegebene Fehleranzahl = Restfehleranzahl * Effektivität (in %)

11.6.2. Zuverlässigkeits-Wachstumsmodelle

Anhand der im Integrations- und Systemtest gesammelten Fehlerwirkungen wird das

Fehlverhalten des Systems im Betrieb errechnet.

Voraussetzungen zur Berechnung sind:

Softwareentwicklungsprozess und Testprozess sind stabil

Testfälle spiegeln die Einsatzbedingungen der Software wider

Testfälle decken alle Fehlerzustände mit grosser Wahrscheinlichkeit auf

Fehlerwirkungen lassen sich eindeutig auf Fehlerzustände abbilden

12. Werkzeuge zur Unterstützung des Testprozesses

12.1. Motivation

Durch den Einsatz von Werkzeugen wird die Automation der Tätigkeiten erreicht.

Werkzeuge entlasten das Personal von mechanischen Tätigkeiten, dadurch wird eine

höhere Motivation erreicht.




12.2. Typen und Nutzer von Testwerkzeugen

12.2.1. Werkzeuge für Management und Steuerung von Tests

Testmanagementwerkzeuge bieten Unterstützung für:

Die Verknüpfung von Anforderungen und Testfällen

Die Verwaltung von Problem- und Fehlermeldungen

Die Verwaltung von Testumgebungsinformationen und Testdaten

Die Verwaltung der Daten über die Anzahl Testfälle und deren Einsatz

12.2.2. Testgeneratoren

Testanalysten verwenden diese Art von Werkzeug hauptsächlich, hiermit kann eine gewisse

Automatisierung der Testfallbeschreibung erreicht werden:

Generatoren erstellen die notwendigen Testdaten - Datenbankbasierte Generatoren - Codbasierte Generatoren - Schnittstellenbasierte Generatoren - Spezifikationsbasierte Generatoren

Beschreibungen lassen sich generieren - durch Generatoren welche den Programmcode analysieren - durch modellbasierte Testgeneratoren welche Testabläufe aus UML Diagrammen ermittlen

12.2.3. Analysewerkzeuge

Folgende Gruppen werden unterschieden

Statische Analysen, prüfen Entwurfsdokumente, analysieren Spezifikationen, prüfen Code

Dynamische Analysatoren, prüfen Programm während der Ausführung

12.2.4. Testdurchführungswerkzeuge

Diese Art wird vor allem für Regressionstests und zur Prüfung von nicht funktionalen

Anforderungen eingesetzt, es bestehen folgende verschiedene Typen

Testroboter oder Capture/Replay Tools

Komparatoren ermittlen Unterschiede zwischen erwartetem und aktuellen Ergebniss

Last- und Performancetools

12.2.5. Weitere Werkzeuge

Debugger

Werkzeuge zur Prüfung von Zugriffs- und Datensicherheit

Webtestwerkzeuge welche Websites auf Fehler prüfen (z.B. ungültige Links)

Fehlergeneratoren bauen Fehlerzustände in das Programm ein




Simulatoren und Emulatoren

12.3. Bewertung und Auswahl von Testwerkzeugen

Eine systematische Werkzeugauswahl erfolgt in folgenden Phasen

1. Entscheidung über Einsatz eines Werkzeuges 2. Identifikation von Anforderungen 3. Evaluation 4. Auswertunge und Auswahl

12.3.1. Grundsätzliche Entscheidung über Einsatz eines Werkzeugs

Identifikation und Quantifizierung von Zielen

Welche Verbesserungen sollen erreicht werden?

Welcher Nutzen soll erzielt werden?

Sollen neue Prozesse eingeführt werden?

Betrachtung möglicher Alternativlösungen

Können die Ziele mit einem Werkzeug erreicht werden?

Kann das Werkzeug erweitert werden?

Kann ein eigenes Werkzeug erstellt werden?

Ist es sinnvoller mit dem Status Quo zu leben

Kosten-Nutzen Analyse

Was sind die direkten Werkzeugkosten (Lizenz, Updates, Wartung)?

Was sind die Kosten der Evaluation?

Was sind die indirekten Kosten (Anpassung Systeme, Schulung, Schnittstellen)

Identifikation von Einschränkungen

Für die Einführung zu negativer Beeinflussung anderer Prozesse?

Durch wen kann die Einführung negativ Beeinflusst werden?

Wodurch kann die Einführung des Werkzeugs scheitern?

12.3.2. Identifikation von Anforderungen

Funktionale Anforderungen an das Testwerkzeug, z.B. Integration in die bestehende Toollandschaft

Nicht funktionale Anforderungen, z.B. einfache Bedienbarkeit, Performance

Anforderungen an Begleitleistungen zum Produkt, z.B. Support, Hersteller

Aufstellung eines Kriterienkatalogs




12.3.3. Evaluation

Selektion der Evaluationskandidaten

Planung und Setup

Bewertung der Werkzeuge anhand der Kriterien

Berichterstellung

12.3.4. Auswahl des zu beschaffenden Werkzeugs

Bewertungsverdichtung und Entscheidungsvorbereitung

Entscheidung

12.4. Einführung von Werkzeugen

12.4.1. Werkzeuge und notwendige Prozessreife

Vor der Einführung eines Werkzeugs müssen die notwendigen Prozessgrundlagen

geschaffen werden.

Das Prozessreifemodell TPI identifiziert die Grundlagen für den Erfolg eines

Werkzeugeinsatzes.

Werkzeuge können bestehende Prozesse positiv beeinflussen und/oder eine Verbesserung

herbeiführen.

12.4.2. Pilotprojekt

Vor der definitiven Einführung soll mittels einem Pilotprojekt der Einsatz des neuen

Werkzeugs geprüft werden.

Im Pilotprojekt müssen nachfolgende Rollen vorhanden sein:

Coach, ist vom Tool überzeugt und managt Probleme

Change-Manager, plant Einführung

Werkzeugverantwortlicher, kennt das Tool, Schnittstelle zu externem Support

Sponsor, finanziert das Werzeug, übernimmt Management Aufgaben

12.4.3. Verbreitung

Es muss ein Rolloutplan erstellt werden:

Verbreitung mittels Big-Bang oder Schrittweise Umstellung?

Was sind die Gesamtkosten der Umstellung?

Wie wird mit Widerständen umgegangen?

Wie wird die Ausbildung sichergestellt?


ISTQB TESTMANAGERNormen und Standards


13. Normen und Standards

13.1. Ziele und Positionierung

Normen und Standards definieren allgemein anerkannte Regeln der Technik und den

fachlich-rechtlichen Bezugsrahmen innerhalb dessen sich Projekte abspielen.

Verantwortlich für Normierungen sind

International, ISO und IEC

Europäisch, CEN, CENELEC

National, DIN, SNV (Schweiz), ON (Österreich)

USA, ANSI

UK, BS

Für den Bereich Softwaretest gibt es folgende Boards:

ISTQB

GTB (Deutschland)

STB (Schweiz)

ATB (Österreich)

13.2. Firmenstandards

Grosse, internationale Firmen kennen zudem eigene Standards, diese können sein

Speziell zugeschnittene Vorgehensmodelle

Qualitätsmanagementhandbücher

Testhandbücher

Vorlagen für Dokumente

Programmier- und Entwurfskonventionen

13.3. Best Practices und technische Spezifikationen

Best Practices sind nicht standardisierte, aber fachlich bewährte Vorgehensweisen und

Verfahren, die zum Stand der Technik eines Fachgebiets gehören.

Weltweit schliessen sich oft Firmen in Konsortien zusammen um solche Best Practices zu

erstellen, welche später in Normen umgewandelt werden können.

13.4. Branchenspezifische Normen und Standards

Es gibt für viele Branchen spezifische Standards

Luftfahrt

Raumfahrt

Militär

Medizintechnik

Pharmazie


ISTQB TESTMANAGERNormen und Standards


Bahntechnik

Nukleartechnik

Telekommunikation

13.5. Allgemeingültige Normen und Standards

Neben branchenspezifischen gibt es auch in der IT allgemein gültige Normen, hierzu zählen

ISO/IEC

IEEE

Normen und Standards werden hier noch weiter unterteilt in:

Terminologienormen, Definition des Anwendungsbereichs

Prinzipiennormen, Prinzipien des Anwendungsbereichs

Elementarnormen, Konformitätsanforderungen für Produkte & Prozesse

Anwendungsrichtlinien, Dokumente mit Anwendungshinweisen

Werkzeug- und Techniknormen, beschreiben Methoden & Techniken


istqb testmanager - firmtec.ch · istqb testmanagergrundlagen [email protected] seite 6 / 52 1....

Documents