Zum Inhalt
wannacode

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

1. Testen des Gutscheincodes: bester Fall 2 Tage, wahrscheinlichster 4, schlechtester 12. Wie lautet die Dreipunktschätzung?
2. In den letzten drei Versionen dauerte das Testen etwa 30 % der Programmierzeit. Das Programmieren ist jetzt auf 20 Tage geschätzt.

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?

1. Was ist ein gutes Eingangskriterium für den Systemtest der Version?
2. Was ist ein gutes Endekriterium?
3. Es ist Freitag, die Freigabe ist am Montag. 70 % der Tests des Gutscheincodes sind gelaufen, ein Fehler mit mittlerem Schweregrad ist offen. Wer entscheidet, ob freigegeben wird?

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.

  1. Rückgaben: unberührt (Wahrscheinlichkeit 1, Auswirkung 3)
  2. Warenkorb-Limit: unberührt (Wahrscheinlichkeit 2, Auswirkung 2)
  3. Gutscheincode: in dieser Version neu geschrieben (Wahrscheinlichkeit 5, Auswirkung 4)
  4. Kartenzahlung: unberührt, aber alles läuft darüber (Wahrscheinlichkeit 2, Auswirkung 5)
  5. Lieferung: die Schwelle wurde geändert (Wahrscheinlichkeit 4, Auswirkung 3)
  6. Seite „Über uns“: die Telefonnummer wurde geändert (Wahrscheinlichkeit 1, Auswirkung 1)

Test

Teste dich

1. Wie wird die Risikohöhe berechnet?
2. Was ist ein Produktrisiko?
3. Warum listet der Plan auch auf, was NICHT getestet wird?
4. Gibt es in einem agilen Team einen Testplan?

Erstellt von Ivo Gergov im Rahmen der Kampagne von Evo Tech für zugängliche Programmierausbildung ·