Der Plan und risikobasiertes Testen
Kurz gesagt: Für das Testen ist immer weniger Zeit da als nötig. Der Plan sagt, was, wie, wer und wann; Eingangs- und Endekriterien sagen, wann man anfängt und wann man aufhört. Das Risiko, Wahrscheinlichkeit mal Auswirkung, ordnet, was zuerst und wie tief getestet wird.
Problem
Vier Tage für zwei Wochen Arbeit
Die neue Version des Shops hat einen neuen Gutscheincode, eine geänderte Lieferschwelle und Korrekturen bei der Zahlung. Die Tester sagen: Wir brauchen für alles zwei Wochen. Die Freigabe ist in vier Tagen, und sie wird sich nicht verschieben, weil die Werbung für die Aktion schon läuft.
Was testest du? Wenn du oben auf der Liste anfängst, prüfst du am vierten Tag immer noch die Seite „Über uns“, und der Gutscheincode geht ungetestet raus.
Die Idee
Der Plan: was, wie, wer, wann
Der Testplan ist die Vereinbarung des Teams über das Testen. Er ist kein Formular, sondern Antworten auf Fragen:
- Was getestet wird und was nicht (Umfang), und warum;
- wie: die Stufen, Arten, Verfahren, was automatisiert wird;
- wer und womit: die Menschen, die Umgebung, die Daten, die Werkzeuge;
- wann: der Zeitplan und die Eingangs- und Endekriterien;
- die Risiken und was dagegen getan wird;
- wie berichtet wird: wer was sieht, und wann.
In einem Wasserfallprojekt ist der Plan ein Dokument. In einem agilen Team ist er eine halbe Seite und ein Gespräch zu Beginn der Iteration. Die Fragen sind dieselben.
Genauer, für Neugierige
Der Testplan steht im CTFL v4.0.1, Abschnitt 5.1.1. Ein Testplan-Dokument nach ISO/IEC/IEEE 29119-3 hat mehr Felder (Kontext, Kommunikation, Risikoregister, Strategie, Personal, Zeitplan). Die Prüfung fragt nach dem Zweck des Plans und seinem typischen Inhalt, nicht nach einer genauen Vorlage.
Die Idee
Wie lange wird es dauern?
Das Testen abzuschätzen ist kein Raten. Es gibt ein paar einfache Verfahren:
- Nach Verhältnissen: In früheren Versionen war das Testen 30 % der Programmierzeit. Das Programmieren sind jetzt 20 Tage, also ist das Testen etwa 6.
- Dreipunkt: Du fragst nach dem besten Fall (a), dem wahrscheinlichsten (m) und dem schlechtesten (b). Die Schätzung ist (a + 4m + b) / 6. Der schlechteste Fall zieht sie nach oben, und das ist ehrlich.
- Mit dem Team: Jeder schätzt allein, dann vergleicht ihr und besprecht den Unterschied. Die Karten des Planning Poker in Agile funktionieren so.
Eine Schätzung ist eine Schätzung. Du nennst sie mit ihrer Annahme: „5 Tage, wenn die Umgebung am Montag bereit ist“.
Genauer, für Neugierige
Der CTFL v4.0.1 nennt in Abschnitt 5.1.4 vier Verfahren: Schätzung nach Verhältnissen, Extrapolation, Wideband Delphi (wovon Planning Poker eine Variante ist) und Dreipunktschätzung. Für drei Punkte gibt der Lehrplan auch die Standardabweichung an: (b − a) / 6.
Probier es aus
Schätze
Die Idee
Wann du anfängst und wann du aufhörst
Das Testen hat kein natürliches Ende: Es gibt immer noch mehr Fehler. Deshalb werden Eingangs- und Endekriterien vereinbart:
- Eingang: wann es sinnvoll ist anzufangen. Die Version ist in der Testumgebung, die Komponententests bestehen, die Testdaten sind geladen, die Stories haben Akzeptanzkriterien.
- Ende: wann du aufhörst. Alle Tests mit hohem Risiko bestehen; es gibt keinen offenen Fehler mit kritischem Schweregrad; die Regressionstests sind grün; die verbleibenden Risiken sind aufgeschrieben und akzeptiert.
Ein Kriterium wird geprüft, nicht gefühlt. „Wir sind bereit“ ist eine Meinung, „0 offene kritische Fehler“ ist eine Tatsache.
In einem agilen Team stehen die Endekriterien einer Story in der Definition of Done und die Eingangskriterien in der Definition of Ready.
Probier es aus
Können wir anfangen? Können wir aufhören?
Die Idee
Das Risiko sagt, was zuerst kommt
Vollständiges Testen ist unmöglich, und die Zeit reicht nicht. Die Frage ist, was zuerst und am tiefsten getestet wird. Die Antwort ist das Risiko.
Ein Risiko ist etwas, das passieren kann und Schaden anrichtet. Es hat zwei Maße:
- Wahrscheinlichkeit: Wie wahrscheinlich ist hier ein Fehler? Neuer Code, komplexer Code, in Eile geänderter Code, Teile mit bisher vielen Fehlern;
- Auswirkung: Wie viel Schaden entsteht, wenn es einen gibt? Geld, viele Kunden, das Gesetz, der Ruf.
Die Risikohöhe ist Wahrscheinlichkeit mal Auswirkung. Der Gutscheincode, von Grund auf neu geschrieben (Wahrscheinlichkeit 5), der Geld verschenken kann (Auswirkung 4), liegt bei 20. Die Seite „Über uns“ mit einer neuen Telefonnummer bei 1.
Risikobasiertes Testen ordnet die Tests nach dieser Zahl: Hohes Risiko wird zuerst getestet, mit mehr Verfahren und mehr Fällen; niedriges Risiko zuletzt oder nur mit einem kurzen Blick. Wenn die Zeit ausgeht, ist das, was ungetestet bleibt, das Ungefährlichste.
Genauer, für Neugierige
Das Risiko steht im CTFL v4.0.1, Abschnitt 5.2. Der Lehrplan unterscheidet Produktrisiken (das Produkt tut nicht, was es soll: eine falsche Summe, ein langsamer Warenkorb) von Projektrisiken (etwas behindert die Arbeit: eine verspätete Umgebung, eine kranke Person). Die Produktrisikoanalyse hat zwei Teile, Identifizierung und Bewertung, und die Risiken werden durch Minderung (Testen) und Überwachung beherrscht. Die Skalen 1–5 hier sind ein Beispiel: In der Praxis gibt es auch Skalen wie niedrig, mittel, hoch.
Übung
Risikobasiertes Testen
1. Ordne nach Risiko. Die vier Tage vom Anfang. Ordne die Teile des Shops in der Reihenfolge, in der du sie testest: das höchste Risiko (Wahrscheinlichkeit mal Auswirkung) oben.
Ordne vom höchsten Risiko zum niedrigsten.
Rückgaben: unberührt (Wahrscheinlichkeit 1, Auswirkung 3)Warenkorb-Limit: unberührt (Wahrscheinlichkeit 2, Auswirkung 2)Gutscheincode: in dieser Version neu geschrieben (Wahrscheinlichkeit 5, Auswirkung 4)Kartenzahlung: unberührt, aber alles läuft darüber (Wahrscheinlichkeit 2, Auswirkung 5)Lieferung: die Schwelle wurde geändert (Wahrscheinlichkeit 4, Auswirkung 3)Seite „Über uns“: die Telefonnummer wurde geändert (Wahrscheinlichkeit 1, Auswirkung 1)
Der Gutscheincode ist 5 · 4 = 20, die Lieferung 4 · 3 = 12, die Zahlung 2 · 5 = 10, das Limit 2 · 2 = 4, die Rückgaben 1 · 3 = 3, „Über uns“ 1 · 1 = 1. Die Zahlung steht an dritter Stelle, obwohl sie den größten Schaden anrichtet: Niemand hat sie angefasst. Aber sie fällt nicht aus dem Plan: Ihre Regressionstests sind automatisiert und laufen bei jeder Änderung.
Test
Teste dich
Verwandte Lektionen
Abschnitt „Verwandte Lektionen“- Baut auf: Wer mitzureden hat · Akzeptanzkriterien · Teststufen · Testarten
- Geht weiter in: Fehler und der Fehlerbericht · Leistung und Last · Informationssicherheit als Anforderung · Tests in der CI
- Aufgaben zum Thema: Stufen, Arten und Prozess