Testrisiken

Diskussionspapier des Arbeitskreises Testmanagement

Risikoorientiertes Testen und Testmanagement

Stand: 22.06.2004

Einleitung

Im Arbeitskreis Testmanagement werden schwerpunktmäßig einzelne Themen diskutiert, die dem Erfahrungsaustausch der Teilnehmer dienen. Es besteht nicht der Anspruch, alle Details eines Gebiets auszuleuchten oder zu einem Konsens zu kommen. Die Diskussionspapiere dienen dem Zweck, gemeinsame Positionen für die weitere Diskussion zu fixieren sowie weiterführende Materialien zu sammeln.

Es werden Ansatzpunkte geliefert, jedoch keine fertigen Lösungen im Sinne von "Best Practices".

Die nachfolgenden Abschnitte dienen der Einführung in das Thema "Risikoorientiertes Testen und Testmanagement". Dazu wird zunächst eine Begriffsdefinition geliefert. Anhand von Beispielen werden diese anschließend verdeutlicht. Zentral ist ein Abschnitt über den Nutzen "risikoorientierten Testens"

Den Schluß bildet eine kommentierte Literaturliste, die es Teilnehmern und Lesern ermöglichen soll, sich selbst weiter mit diesem Thema zu befassen.

Definitionen

Im folgenden soll der Begriff des Risikoorientierten Testens näher gefaßt werden. Dies soll einerseits durch eine Abgrenzung gegenüber einem Entwicklungsumfeld geschehen andererseits durch die Einordnung in das Testmanagement-Schema (Vgl. Arbeitspapier Testmanagement des Arbeitskreises).

Risiko und Risikomanagement

Risikobetrachtungen sind im Projektmanagement zur Software-Entwicklung zunächst nichts Neues. Sowohl der Auftraggeber, als auch der Hersteller entwickeln eine Sicht auf die mit der Inbetriebnahme des Softwareprodukts oder dessen Entstehung verbundenen Risiken.

Zur Bestimmung und zum Umgang mit Risiken bestehen also bereits Verfahren, die auch das Rahmenwerk zur Beschreibung des risikoorientierten Testens herangezogen werden können.

Amdahl gibt in seinem Artikel eine kurze Einführung in die Aufgaben und Ziele des Risikomanagements. Nachfolgend wird diese Beschreibung kurz zusammengefaßt:

Aufgaben des Risikomanagements sind:

1. Identifikation von Risiken
2. Entwicklung einer Risiko-Strategie
3. Bewertung von identifizierten Risiken (Eintrittswahrscheinlichkeit, Kosten)
4. Aktivitäten zur Vermeidung von Risiken bzw. zur Begrenzung des Schadens
5. Berichterstattung über Risiken
6. Erstellung von Prognosen über die Entwicklung von Risiken
7. Evt. Definition von Maßnahmen im Schadensfall.

Das Risiko selbst wird bewertet als Produkt aus der Eintrittswahrscheinlichkeit und der Größe des Schadens:

                C(c) + C(v)
R(f) = P(f) *  ------------
                     2
              
          

Tritt ein möglicher Schaden, der im Risikomanagement betrachtet wurde, tatsächlich ein, endet das Risikomanagement und wird durch das "Krisenmanagement" abgelöst.

Risiken in der Software-Entwicklung

Innerhalb eines Projekts oder einer Projektaufgabe ist grundsätzlich zu unterscheiden zwischen dem Produkt-Risiko und dem Prozeß-Risiko. Das Produkt-Risiko hat die Schäden zum Gegenstand, die aus dem Einsatz bzw. der Nutzung des (fertigen) Softwareprodukts entstehen. Das Prozeß-Risiko faßt Schäden, die aus dem Herstellungsprozeß resultieren, z.B. Verzögerungen oder höhere Herstellungskosten.

Sowohl der Hersteller eines Produkts, als auch der spätere Nutzer sind von beiden Risikoarten betroffen, wenn auch in unterschiedlicher Weise. Es ist daher durchaus sinnvoll, wenn der Nutzer dem Hersteller seine Sicht auf das Produkt bezüglich der Risiken mitteilt.

Innerhalb eines Softwareprojekts bestehen - werden die unterschiedlichen Teilaufgaben betrachtet - ebenfalls solche Hersteller-Nutzer-Schnittstellen, an denen Informationen über Risiken bzw. die unterschiedlichen Sichtweisen darauf ausgetauscht werden.

Es wird davon ausgegangen, daß während der Software-Entwicklung die Entwicklungs- und Testaufgaben organisatorisch getrennt werden.

Es wird weiter angenommen, daß in einem Softwareprojekt jeder Verantwortliche eine Risikobetrachtung für sein Aufgabengebiet durchführt, z.B.:

1. Auftraggeber: Geschäftsrisiken beim Betrieb
2. Auftragnehmer: Risiken bei der Herstellung des SW-Produkts
3. Realisierungs-Leiter: Risiken bez. den Entwicklungsaufgaben
4. Test-Leiter: Risiken bez. den Testaufgaben

Unter dem Gesichtspunkt Risikomanagement im Gesamtprojekt spielt Testen eine wichtige Rolle, es ist

1. eine Informationsquelle für den Eintritt von erkannten Risiken
2. eine Maßnahme im Rahmen der Risikovermeidung bzw. Schadensbegrenzung
3. ein wichtiges Prognoseinstrument

Im weiteren soll für Testen und Testmanagement zwischen folgenden Risiken unterschieden werden:

1. Projektrisiko

• Dies betrifft das gesamte Softwareprojekt, Verzögerungen, Budget-Überschreitungen und umfaßt auch das Produktrisiko des Projekts.

2. Produktrisiko
• Dies betrifft Mängel des Gesamtprodukts, z.B. nicht realisierte Anforderungen, Designprobleme bzw. Fehler in der Implementierung. Es ist Aufgabe des Testens, diese rechtzeitig zu erkennen.
3. Testprozeßrisiko
   • Unter dem Titel Testprozeßrisiko sollen Risiken zusammengefaßt werden, deren Ursache in den Testmanagementprozessen oder den Basisprozessen des Testens anzusiedeln sind.

In der weiteren Diskussion sollen Fragen des allgemeinen Risikomanagements nur insofern betrachtet werden, wie sie im Testmanagementprozeß Berücksichtigung finden müssen. Produkt- und Projektrisiken werden dabei als "äußere" Risiken begriffen, während die Prozeßrisiken als "innere" gelten.

Selbstverständlich bestehen auch bezüglich der Produkte des Testens gewisse Risiken. Grob gesprochen handelt es sich dabei schlicht um Falschaussagen zum Produktrisiko des Gesamtprojekts. Das Gesamtprodukt selbst wird durch die falsche Information nicht besser oder schlechter. Die Aussage verhindert aber möglicherweise eine rechtzeitige Korrektur oder Verbesserungsmaßnahmen.

Risiken in den Testprozessen

Zur Betrachtung von Risiken wurde das Testmanagement-Schema so erweitert, daß sich auch die "äußeren" Risiken erfassen lassen. Die Vorprodukte beschreiben dabei die Produkte anderer Projektaufgaben, soweit sie in den Testprozeß Eingang finden, z.B. die Spezifikationen oder die zu Testende Software. Es wird weiter davon ausgegangen, daß Informationen über bereits erkannte Risiken mitgeteilt werden.

Bei den Produkten des Testens wird nun unterschieden zwischen den Aussagen über das Produktrisiko (des Gesamtprojekts) und Aussagen über Fehler in der Software. Erstere werden vom Risiko-Management des Gesamtprojekts verarbeitet, letztere fließen direkt oder indirekt zur Realisierungsaufgabe zurück.

Im weiteren wird versucht, den Begriff "risikoorientiertes Testen" unter zwei verschiedenen Aspekten zu betrachten:

1. Risikoorientiertes Lenken und Gestalten von Testaufgaben
2. Risikoorientiertes Testen in den Basisprozessen

Eine eindeutige Zuordnung der beiden Aspekte zu den Testprozessen wird nicht immer gelingen, da es sicher immer Grauzonen zwischen den Prozessen Gestalten und Vorbereiten einerseits oder Lenken und Durchführen andererseits geben wird, die sich allein in der konkreten Projektsituation zuordnen lassen.

Risikoorientiertes Lenken, Gestalten und Bewerten von Testaufgaben

Die Aufgabe des Gestaltens ist die Erstellung des sog. Rahmentestplans, der unter anderem folgende Themen behandeln sollte

1. Prüfgegenstand festlegen
2. Referenzdokumente identifizieren
3. Anforderungen an Test aufnehmen:
4. Testziele festlegen
5. Teststrategie festlegen
6. Voraussetzungen für Basisprozesse definieren
7. Meßbare Testende- und Testabbruch-Kriterien festlegen
8. Methodenbündel auswählen
9. Werkzeugauswahl
10. Machbarkeit prüfen
11. Schnittstellen zu anderen (Teil-)Projekten definieren

Im wesentlichen werden beim Gestalten die Vorgaben für die Basisprozesse erstellt und während des Lenkens werden die Basisprozesse entsprechend gesteuert und überwacht. Die Bewertung schließlich ist in diesem Sinne das Erstellen von Informationen über eingetretene oder ausgeschlossene Risiken bez. des Produkts. Nicht jeder gefundene Fehler ist zugleich relevant bez. der betrachteten Risiken.

Risikoorientiertes Lenken, Gestalten und Bewerten von Testaufgaben befaßt sich entsprechend mit den Projekt- und Testprozeßrisiken.

Hier werden die erkannten oder ermittelten Produktrisiken genutzt, um die generellen Richtlinien für die Durchführung der eigentlichen Testaufgaben (Basisprozesse) bzw. die Struktur der Tests festzulegen und zu überwachen.

Weiter werden hier Maßnahmen definiert bzw. ergriffen, falls Projektrisiken (z.B. Verzögerungen oder mangelhafte Vorprodukte) eingetreten sind und Änderungen im geplanten Ablauf erfordern.

Im Großen und Ganzen läuft alles auf eine Optimierungsaufgabe hinaus:

Es geht darum, die Kosten und die für den Test benötigte Zeit zu minimieren. Andererseits gilt es auch, die größten Risiken zuerst zu untersuchen, damit noch genügend Zeit für Gegenmaßnahmen bleibt.

1. Produktrisiken müssen Bestandteil der Anforderungsdefinition für das Testen sein.
2. Aus der Spezifikation des möglichen Schadens im Fachkonzept läßt sich eine Priorisierung der Testaufgaben ableiten.
3. Dazu sind die fachlichen und technischen Risiken soweit auf konkrete Fragestellungen herunterzubrechen, daß sie in Testfälle umgesetzt werden können.
4. Eine Risikoabschätzung muß die Grundlage der Testfallermittlung werden. Diese Risiken müssen dann während des Testens beobachtet werden (Traceability).
5. Ein Ansatz risikoorientierten Testens könnte darin bestehen, Tester mit der Aufgabe zu betrauen, Testfälle für ein spezifisches Risiko zu entwerfen, anstelle einer testobjektbezogenen Aufgabenstellung.

Hier wird deutlich, daß die Risikoorientierung in alle genannten Aufgabenbereiche des Gestaltens Eingang finden muß.

Erfahrene Tester werden sicher in der Lage sein, auch selbständig Risiken zu identifizieren. Falls das Produktrisiko aber nicht Eingang in den Testprozeß findet, hat es etwa denselben Effekt, wie eine fehlende Spezifikation, eine gezielte Aussage über das Produktrisiko wird dann unmöglich.

Risikoorientiertes Testen in den Basisprozessen

Die Basisprozesse befassen sich mit den inhaltlichen Fragen der Testaufgabe, hier werden entsprechend die generellen Vorgaben z.B. in Form eines Testplans oder von Testfällen ausgearbeitet. Während der Durchführung oder Nachbereitung von Tests, kann dann über die Bewertung der Testergebnisse eine Auswertung mit Bezug zu identifizierten Risiken erfolgen.

Risikoorientiertes Testen in den Basisprozessen befaßt sich einerseits mit der Berücksichtigung der identifizierten Produktrisiken in der Ermittlung und/oder der Auswahl von Testfällen und erzeugt daraus Informationen über diese Risiken.

Sofern im Gestaltungsprozeß geeignete Vorgaben gemacht werden, können Risiko-Aspekte in den Basisprozessen berücksichtigt werden. Nicht zu unterschätzen ist auch die Fähigkeit erfahrener Tester, die kritischen Punkte der Software "intuitiv" zu erfassen - insbesondere dann, wenn keine Vorgaben gemacht wurden.

Andererseits sind die Basisprozesse auch der Ort, an dem selbst Fehler passieren können (es soll aber nicht ausgeschlossen werden, daß während des Gestaltens und Lenkens nicht auch etwas falsch gemacht werden könnte). Hier ist also eine wichtige Quelle für die sog. Testprozeßrisiken anzusiedeln. Während des Gestaltens und Lenkens muß für diese Risiken ebenfalls Vorsorge getroffen werden.

Der Umgang mit diesen Testprozeßrisiken ist aber von je her Aufgabe des Testmanagers.

Erwartungen und Nutzen

Die folgenden Stichpunkte beziehen sich auf die Erwartungen und Nutzenaspekte in Verbindung mit einem risikoorientierten Testansatz.

1. Mit einem risikoorientierten Testansatz haben wir als Testmanager ein Instrumentarium in der Hand, um uns bei der Planung auf das Wesentliche zu konzentrieren.
• Von daher unterstützt dieser Ansatz den Umgang mit beschränkten Ressourcen und priorisiert die Testgegenstände hoch, bei denen die höchsten Risiken erkannt wurden.
• Hohe Risiken sind bei den Testgegenständen zu lokalisieren, bei denen die potentiellen Schäden am höchsten sind.
2. Ein risikoorientierter Testansatz kommuniziert gegenüber dem Management fortlaufend den positiven Beitrag des Testens zur Risikominimierung und stellt damit die Darstellung der Wirtschaftlichkeit in den Mittelpunkt der Berichterstattung ("business value").
   • Es erfolgt keine negative Berichterstattung: Wir haben wieder X Fehler gefunden !!
   • Ausgangspunkt ist hier die Sicht, daß vorhandene Risiken erwartete Benefits blockieren.
   • Testfälle sollen zeigen, daß die Risiken nicht existieren, die Benefits somit realisiert werden können.
   • Erfolgreich durchgeführte Tests zeigen, welche Benefits up-to-date bereits realisiert werden können.
   • Noch nicht durchgeführte Tests verdeutlichen, welche Benefits potentiell noch blockiert sind.
   • Das Management ist aufgefordert zu entscheiden, diese Risiken zu tragen, falls das Testbudget z.B. gekürzt werden soll.

3. Ein risikoorientierter Testansatz ermöglicht dem Testmanagement und dem Testdesign eine frühe Einbeziehung in den gesamten SW-Entwicklungsprozeß.
   • Die Identifikation der Risiken und die Priorisierung der Tests wird vom Testmanagement zusammen mit den Business Experten gemacht (i.d.R.: Fachabteilung).
   • Diese Aktivitäten sollten früh aufgesetzt werden - während/nach der Requirementsphase.
   • Keine Freigabe, wenn die "Musts" nicht getestet wurden.
   • Strategisch werden die wichtigen Teile zuerst getestet und freigegeben während andere verspätet werden.

4. Ein risikoorientierter Testansatz ist eng verzahnt mit einer Betrachtung des SW-Entwicklungsprozesses (Schwachstellen im Entwicklungsprozeß, kritische Systemteile mit erwarteter hoher Fehlerrate, neue Technologien, Team mit hohem Anteil an Beginners etc.) und ist von daher geeignet, den je aktuellen Stand der Entwicklung zur Grundlage der Testaktivitäten zu machen und die Weiterentwicklung des Gesamtprozesses positiv zu unterstützen.

5. Vor allem unter Zeit- und Budgetdruck kann mit Hilfe der Risikoorientierung der Testprozeß ergebnis- und zielorientiert gesteuert werden.

   Beispiele

   Beispiele für Risiken, die während des Testens berücksichtigt werden können sind:

   1. Projektrisiken
      • Testprojektauftrag fehlt
      • Testziele unvollständig
      • Rahmenbedingungen für den Test unbekannt
      • Testeingangs-Kriterien undefiniert
      • Problemmanagement nicht verfügbar
      • Change- und Konfigurationsmanagement fehlt
      • Übergabe-/Übernahmeprozesse undefiniert
      • Berichtswesen (Status, Fortschritt, Eskalation) unklar
      • Testdokumentation schlecht
      • Implementierung für Funktion x fällt aus
      • Vorprodukte mangelhaft
      • Unerfahrenes Entwicklerteam
      • Lernkurve bei der Einführung neuer Techniken falsch eingeschätzt

   2. Testprozeßrisiken
      • Zeitvorgaben unrealistisch
      • Budget zu gering
      • Personal unzureichend qualifiziert
      • Infrastruktur unzureichend
      • Produkte des Testens undefiniert
      • Kontrolle von Terminen, Kosten, Budget, Personal unzureichend
      • Auswahl der Testmethoden und -werkzeugen ungeschickt
      • Abbruchkriterien undefiniert

   Mittel risikoorientierten Testens

   In der Diskussion blieben die verfügbaren Mittel, um risikoorientiert zu testen, immer etwas diffus.

   Angenommen, die Produktrisiken seien bekannt, dann:

   1. kann eine Zuordnung Testfall-Risiko vorgenommen werden
   2. ist jeder gefundene Fehler eine Information über ein Risiko
   3. kann das Testende in Kategorien der Risikoabdeckung definiert werden
   4. berichten wir nicht über Fehler sondern über Risiken
   5. können die erforderliche Teststufen daraus abgeleitet werden
   6. ergibt sich eine Reihenfolge bzw. Priorisierung für die Testfälle
   7. ergibt sich ein Einfluß auf die Auswahl von Testmethoden
   8. kann u.U. eine Konzentration auf bestimmte Fehlerklassen erfolgen
   9. lassen sich vielleicht Testbarkeitsanforderungen besser addressieren

   Literatur

   In der kommentierten Literaturliste sind Hinweise auf hier nicht näher betrachtete Aspekte des risikoorientierten Testens zu finden.

   Zusammengefaßt gibt es verschiedene Positionen:

   1. Testen war schon immer risikoorientiert
   2. Risikoorientiertes Testen dient der Informationsbeschaffung über Risiken.
   3. Die Risikoorientierung kann fehlende Spezifikationen ersetzen
   4. Risikoorientierung liefert eine neue, positivere, verständlichere Möglichkeit über Testen und Testergebnisse zu sprechen.
   5. Möglichkeiten zur Priorisierung bzw. Strukturierung des Tests werden fast überall gesehen.
   6. Gelegentlich wird auf eine Liste von Software-Fehlern verwiesen, um Risiko-Kataloge zu erstellen.

   Schluß

   Während des Testens werden Informationen über den Eintritt zuvor benannter Risiken ermittelt. Damit ist der Test immer ein wichtiger Indikator für den Risiko-Manager eines Software-Projekts.

   Darüber hinaus liefert der Test u.U. Informationen über noch nicht erkannte/benannte Risiken.

   Die Mittel, über die diskutiert bzw. über die geschrieben wurden, erscheinen nicht so revolutionär, daß sich daraus irgend etwas Besonderes ergäbe. Es hat schon immer eine Priorisierung von Testfällen stattgefunden - in die sicher auch immer alle benannten Risiken Eingang gefunden haben. Es spricht also nichts dagegen, bewährte Methoden, wie z.B. die ABC-Analyse einzusetzen, um zu einer geeigneten Priorisierung zu kommen.

   Der wichtigste Effekt entsteht möglicherweise dadurch, daß ein Klima geschaffen wird, in dem über Fehler in einem positiven, konstruktiven Sinne gesprochen werden kann.

    

   Kommentierte Literaturliste "Risikoorientiertes (-basiertes) Testen"

   Im folgenden werden Literaturstellen nachgewiesen, die im Laufe der Zeit im Arbeitskreis gesammelt worden sind. Die Kommentare sind persönliche Positionen einzelner Arbeitskreis-Teilnehmer und als solche zu verstehen. Ein Anspruch auf Objektivität oder Vollständigkeit wird nicht erhoben.

   Damit sich jeder selbst einen Überblick verschaffen kann, wurden, soweit möglich, die Links zu den ursprünglichen Fundstellen angegeben. Diese Links werden nicht weiter gepflegt und die Gültigkeit kann zu keinem Zeitpunkt garantiert werden. In keinem Fall ist der Arbeitskreis verantwortlich für den Inhalt der Web-Seiten, auf die im folgenden verwiesen wird.

   
   

   [1]

   Hetzel, B.: The complete Guide to Software Testing. QED Information Sciences: Wellesley, Massachusetts, 2nd ed., S. 24, 1988.

   Hetzel sieht Testen grundsätzlich als risikobasiert an. Beim ihm bedarf dies keiner weiteren Erläuterung, z.B. S. 24:

   "Testing Principle 4 - Testing Is Risk-Based
   How much testing would you be willing to perform if the risk of failure or missing a defect were negligible? Alternately, how much testing would you be willing to perform if a single defect could cost you your life's savings, or, even more significantly, your life? [...]"

   So ganz neu ist das Thema also nicht.

   [2]

   Kaner, C., Bach, J. Pettichord, B.: Lessons Learned in Software Testing. A Context-Driven Approach. Wiley: New York, 2001.

   Die Autoren sehen im wesentlichen zwei Bedeutungen für den Begriff risikobasiertes Testen (Vgl. S.39):

   1. Eine Risikoanalyse bestimmt, welche Gegenstände als nächstes getestet werden. Der Test wird in Begriffen der Eintrittswahrscheinlichkeit für einen Fehler und dessen möglichen Kosten priorisiert.
   2. Die Eintrittswahrscheinlichkeit für spezifische im Produkt enhaltene Fehler wird anhand der Produkteigenschaften bzw. dessen Herstellungsprozeß bewertet und bestimmt dann die Struktur des Tests.

   Die Autoren favorisieren die zweite der genannten Bedeutungen und suchen daher nach sog. "risk drivers". Ist dies nicht eigentlich dasselbe, was bereits '79 bei Myers zu lesen war, daß nämlich diejenigen Testfälle auszuwählen seien, die mit der höchsten Wahrscheinlichkeit einen Fehler zu Tage fördern?

   [3]

   Rice, R. W.: A Risk-based Approach to Client/Server Testing. Rice Consulting Services, Inc. 1995-2000.

   Der Autor schlägt vor, zunächst Gefahren und Erfolgsfaktoren auszuwählen und zu bewerten. Anhand der Bewertung werden anschließend Teststrategie und Testplan entwickelt. Der Artikel ist eher kurz, liefert aber eine praktikable Checkliste zum Vorgehen.

   [4]

   Amland, S. Risk Based Testing and Metrics. Risk Analysis Fundamentals and Metrics for software testing including a Financial Application case study. 5th Intern. Conf. EuroSTAR '99, November 8 - 12, 1999, Barcelona, Spain.

   Ausgezeichneter Beitrag, der von einer Einführung in die Risikoanalyse bis hin zu in einem Projekt ermittelten Kennzahlen reicht. In [2] wird dieser Beitrag als Referenz zur ersten angegebenen Bedeutung risikobasierten Testens referenziert. Link: http://www.amland.no/WordDocuments/EuroSTAR99Paper.doc

   [5]

   Bach, J.: Risk and Requirements-Based Testing IEEE Computer, S. 113-114, June 1999.

   Sehr kurzer Beitrag, der risikobasiertes Testen als Ersatz für fehlende bzw. unvollständige Requirements vorschlägt. Link: http://www.satisfice.com/articles/requirements_based_testing.pdf

   [6]

   Gerrard, P.: Risk-Based Test Reporting. Systeme Evolutif, 14 February 2001.

   In knapper Form wird vorgeschlagen, den Fortschritt beim Testen nicht in der Anzahl der Testläufe oder Fehler zu berichten, sondern in Form ausgeschlossener bzw. offener Risiken. Während des Testens kann weiter festgestellt werden, welche offenen Risiken das Erreichen von Zielen oder den angestrebten Nutzen behindern. Bereits ausgeschlossene Risiken sind im Falle von Regressionstests jeweils neu zu bewerten.

   [7]

   Ottevanger, I. B.: A Risk-Based Test Stratgy. IQUIP Informatica B.V., 1999.

   Der Beitrag liefert eine Beschreibung, wie Risikobetrachtungen (hier Business Risks) die Gestaltung von Tests beeinflußen können, ohne daß auf angestammte Qualitätsmerkmale in der Bewertung verzichtet wird. Als Ziel wird festgehalten, daß die "wichtigsten" Fehler zuerst gefunden werden müssen, damit einerseits das Eintreten eines Schadens noch verhindert werden kann bzw. die Kosten zur Behebung des Fehlers möglichst gering ausfallen. Zugrunde gelegt werden auch hier verschiedene produkt- und prozeßbezogene "risk drivers". Weiterhin wird gezeigt, wie das gesamte Verfahren auf Teststufen und Sysbsysteme heruntergebrochen werden kann. Link: http://www.stickyminds.com/se/S2056.asp

   [8]

   Pettichord, B.: Information and Risk-Based Testing. Präsentation. Satisfice, Inc., 2001.

   Der Autor schlägt vor, das Risiko einmal nach dem zu erwartenden Schaden und zum anderen nach der verfügbaren Information über dessen Eintritt zu klassifizieren. Danach wird Testen als erforderliche Maßnahme im Entwicklungsprozeß dargestellt, wenn der erwartete Schaden hoch, das Wissen darüber jedoch gering ist, z.B. S. 27:

   "Gaining information about risk becomes a context for the testing mission"

   Darüber hinaus wird empfohlen, einen sog. "Risk Catalog" aufzustellen, der sowohl Qualitätskriterien, Risikofaktoren und mögliche Fehler umfaßt. Link: http://www.io.com/~wazmo/papers/information_and_risk-based_testing.pdf

   [9]

   Bach, J.: Heuristic Risk-Based Testing. Software Testing and Quality Engineering Magazine, 11/99.

   Der Artikel befaßt sich in erster Linie mit der Identifikation von Risiken. Dazu bietet er verschiedene Listen und Kataloge an. Nett zu lesen, z.B.:

   "Isn't all testing risk-based?"
   To answer that, look at food. We all have to eat to live. But it would seem odd to say that we do 'food-based living'. Under normal circumstances, we don't think of ourselves as living from meal to meal. [...] However, when we are prone to eat too much, or we suffer food allergies, or when we are in danger of running out of food, then we may as well plan our lives explicitely around our next meal. Same with risk and testing."

   Link: http://www.satisfice.com/articles/hrbt.pdf

   [10]

   Kaner, C. Falk, J., Nguyen, H. Q.: Testing Computer Software. Wiley: New York, 2nd ed., S. 363 ff.. 1999.

   Anhang A dieses Buches mit der Überschrift "Common Software Errors" wird immer wieder in den verschiedenen Veröffentlichungen erwähnt, die sich mit Risikofaktoren oder -Katalogen auseinandersetzen. Die Quellen allen Übels, sozusagen.

   [11]

   Payne, J. E.: Quality meets the CEO. How to get Management buy-in. Software Testing and Quality Engineering Magazine, May/June 1999.

   Der Autor beschreibt sehr drastisch, wie ein CEO Entscheidungen trifft, wie deshalb mit dem Management zu kommunizieren ist und wie die Tester beim Management glaubwürdig werden. Es geht dem Management nicht um Fehler und erfüllte ISO 9000, sondern um Profit, Markanteile und Risiken. Deshalb sollte ein Tester sich überlegen: kurzfristiger ROI seines Vorschlages, langfristiger ROI seiner Vorschlages, Risiko eines Fehlschlages usw. Link: http://www.stickyminds.com/sitewide.asp?ObjectId=2612&ObjectType=ART&Function=edetail&tt=nl&URLforBack=http://www.stickyminds.com/stqeletter/archive/20010704.asp&URLTitle=Back%20to%20Archived%20STQe-Letter&tt=nl

   [12]

   o.A.: Der Coconut-Effekt als Risikobewußtwerdungsprozess. io management, S. 25. 11/1999.

   In dem Artikel wird der psychologiche Unterschied zwischen abstraktem Risiko (Erkenntnis) und realem Hinweis (subjektive Risikoanerkennung) erläutert: "Durchgang verboten" versus "Fallende Kokusnüsse! Bitte fernhalten!"

   [13]

   Bullock, J.: Calculating the Value of Testing. How to present testing as a business-process investemt. Software Testing and Quality Engineering Magazine, May/June 2000.

   In diesem Artikel werden 7 Fragen des Managements an das Testen aufgeworfen und 3 häufige Fehler bei der Kommunikation mit dem Management benannt ("The endless narrative", "Selling features, not benefits", "The one true thing"). Link: http://www.stickyminds.com/sitewide.asp?ObjectId=2590&ObjectType=COL&Function=edetail&tt=nl&URLforBack=http://www.stickyminds.com/stqeletter/index.asp&URLTitle=Back%20to%20STQe-Letter&tt=nl

   [14]

   Muessig, P.R., et al.: Optimization of VV&A Activities - a Risk/Benefit Appraoch. ACM, Proc. of the 1997 Winter Simulation Conference, pp. 60, 1997.

   Beschäftigt sich mit der Frage, wie eine Menge von Maßnahmen zur Verifikation und Validierung auf der Basis einer Risiko/Nutzen-Analyse ausgewählt werden kann.

   • Arbeitet mit einer äquivalenten Formel für Risiko Risk = (Impact Level) x (Propability of Occurrence)
   • Hebt hervor, daß es wichtig ist, die Qualität/Zuverlässigkeit/Glaubwürdigkeit der Informationen bewerten zu können, auf denen basierend Aussagen über Risiken getroffen werden
   • Berücksichtigt bei der Bewertung der Wahrscheinlichkeit, daß es nicht nur darauf ankommt, eine Instanz der Software zu bewerten. Gerade im Massenmarkt ist es auch wichtig, zu beurteilen, wieviele Kunden ein Risiko potentiell betrifft
   • Geht im Prinzip davon aus, daß Risiken nie ausgeschlossen werden können, weswegen sie gegen einen möglichen/erwarteten Nutzen abgewogen werden müssen. Also die Frage, ob ein Produkt freigegeben werden soll obwohl sehr wahrscheinlich Fehler enthalten sind.
   • Ausgehend von der erfolgten Risikobewertung werden Maßnahmen vorgeschlagen, die in jedem Fall getroffen werden sollten. Die angegebene Tabelle ist allerdings sehr allgemein gehalten

   [15]

   Boehm B., Port, D.: Educating Software Engineering Students to Manage Risk. IEEE, pp. 591, 2001.

   Auf den ersten Blick uninteressant, da es nicht um Testen geht sondern um Risikomanagement im gesamten Entwicklungsprozeß. Interessant ist aber die Tabelle2, da diese allgemeine Risiken und "Gegenmaßnahmen" auflistet. Nun könnte man ja versuchen, bei der Auswahl der Testfälle zu beurteilen, inwieweit schon andere Maßnahmen zum Umgang mit Risiken getroffen wurden. Je nachdem, welches Vertrauen in diese Maßnahmen gesetzt wird, könnte der Testaufwand an der entsprechenden "Stelle" reduziert werden.

   [16]

   DeMarco T., Lister T.: Waltzing with Bears. Managing Risk on Software Projects New York: Dorset House, 2003.

   Pro und Contra von Projekt-Risiko-Management. Explizit spielt Testen keine Rolle, es findet sich jedoch der Satz: "create an overall final product-acceptance test, [...], one per version" (S. 167). Link: http://www.systemsguild.com/riskology

   [17]

   Schaefer, H.: Strategies for Prioritizing Tests Against Deadlines. Risk based testing: ..., 2002

   Link: http://home.c2i.net/schaefer/testing/risktest.doc

   [18]

   Furtmeier, T.: Testen in Zahlen: Coverage, Metriken, Risikomanagement. Hauptseminar Softwaretest. SS 2002,TU München.

   Links: http://www4.in.tum.de/~pretschn/teaching/testsem02-ausarb/furtmeier-testenzahlen.pdf http://www4.in.tum.de/~pretschn/teaching/testsem02-ausarb/furtmeier-zahlen-folien.pdf

   [19]

   Baltzert, H: Lehrbuch der Software-Technik, Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung. Abschnitt 5.5: Risiken managen, Spektrum, Akad. Verlag, 1998.

   [20]

   ASQF: Grundlagen des Softwaretestens. Lehrplan zum Basiskurs. ASQF-Certified-Tester, Foundation Level ASQF e.V. Version 2.2 07/2003

   Im Basiskurs wird Risiko nur kurz bei der Priorisierung von Testfällen erwähnt. Interessant ist, daß in diesem Lehrplan beim Stichwort "Testmanagement" auf unterschiedliche Aufgabenteilungen zwischen Entwicklung und Test eingegangen wird. Außerdem werden die Aufgaben des Testmanagers erwähnt. Link: http://www.isqi.org/isqi/deu/cert/ct/Lehrplan-Foundation_v2-2-ISTQB.pdf

   [21]

   ASQF: Grundlagen des Softwaretestens. Lehrplan zum Aufbaukurskurs. ASQF-Certified-Tester, Advanced Level ASQF e.V. Version 1.2 07/2003

   Im Aufbaukurs existiert ein eigenes Kapitel "Risikoorientiertes Testen" (nicht risikobasiert :-)). Im Kapitel 3.1.2 (Testhandbuch) wird darauf eingegangen, daß das Testhandbuch Risiken und einen Prozess beschreibt, wie diese Risiken abgeschwächt werden können. Das Kapitel 4 (Risikoorientiertes Testen) geht ähnlich unserem Vorgehen zunächst auf den Begriff "Risiko" ein und beschreibt das Risikomanagement. Link: http://www.isqi.org/isqi/deu/cert/ctal/download/Lehrplan-Advanced_v1-2-ISTQB.pdf

   [22]

   Redmill, F.: Test management: The greatest risk Professional Tester, April 2003.

   Redmill identifiziert 3 Risikogruppen:

   • inhärente Risiken des zu erstellenden Produkts, die mit Hilfe des Testens minimiert werden sollen,
   • Risiken, die durch die Softwareerstellung auf das Testprojekt einwirken können (z.B. Verzögerungen
   • Risiken im Testprojekt selbst.

   Er führt aus, daß in dem turbulenten Umfeld, in dem Testprojekte normalerweise ablaufen, das Testmanagement selbst der größte Risikofaktor sei. Link: http://www.professionaltester.com/archive/apr2003/ProTesterApr2003-Redmill

   [23]

   Quentin, G.: Skills of the Professional Tester. Section 2: Risk-based testing Professional Tester, April 2003.

   Quentin gibt einen kurzen Überblick auf den Einfluß des Risikos auf das Testen. Link: http://www.professionaltester.com/archive/2001/Protester-SkillsOfProTester.pdf

    

   Falls Ihnen ein Titel in dieser Liste fehlt oder Sie einen eigenen Kommentar abgeben möchten, senden Sie Ihren Beitrag bitte an den Arbeitskreis Testmanagement der GI-Fachgruppe TAV. Wir werden die bestehende Liste gern auf Ihren Vorschlag hin ergänzen.