Spring GDS 25. Jubiläum
Ein Logistikunternehmen, das in 190 Länder versendet, hat etwas gebaut, um an sich selbst zu liefern.
Ein Testplan ist das Dokument, das entscheidet, was getestet wird, bevor jemand mit dem Testen beginnt. Umfang, Vorgehen, Zeitplan, Umgebungen, wer was verantwortet und was als bestanden oder gescheitert gilt. Er verwandelt die vage Absicht, "die Funktion zu prüfen", in eine klare Vereinbarung, auf die das ganze Team verweisen kann.
Ein Testplan ist kein Testfall, und die beiden werden oft verwechselt. Der Plan ist die Strategie: welche Funktionen im Umfang liegen, welche bewusst draußen bleiben, welche Risiken am meisten zählen und was vor dem Release wahr sein muss. Ein Testfall ist eine konkrete Prüfung innerhalb dieser Strategie, ein Satz Schritte mit einem erwarteten Ergebnis. Ein Plan enthält viele Fälle. Bevor eine Zahlungsintegration live geht, benennt der Testplan die Umgebungen, die Daten, die Grenzfälle rund um fehlgeschlagene Buchungen und die Ausstiegskriterien, während die Fälle jedes einzelne Szenario ausbuchstabieren.
Gute Pläne setzen auch Eintritts- und Austrittskriterien, damit ein Build nicht halbfertig ins QA kommt und es nicht mit offenen, bekannten Blockern verlässt. Diese Klarheit zählt am meisten, wenn ein Projekt enge Fristen hat, denn sie hält das Team davon ab, über Abdeckung zu streiten, während die Uhr läuft. Im Plan werden diese Entscheidungen bewusst und im Voraus getroffen, statt unter Druck.
Wir schreiben den Plan mit dem Kunden, nicht für ihn. Umfang und Risiko sind Entscheidungen über das Geschäft, also sitzen die Menschen, die das Geschäft verstehen, mit am Tisch, wenn wir festlegen, was zuerst getestet wird und was wir aufschieben können. Der Plan bleibt kurz genug, um wirklich gelesen zu werden, und spezifisch genug, um danach zu handeln.
Von dort aus steuert er die Arbeit. Unsere Qualitätssicherung läuft gegen die Kriterien im Plan, automatisiertes Testen deckt die wiederholbaren Pfade ab, und exploratives Testen kümmert sich um die Ecken, die ein Skript übersähe. Verschiebt sich der Umfang mitten im Projekt, und das tut er meist, aktualisieren wir den Plan offen, damit niemand eine Abdeckungslücke in der Produktion entdeckt. Das Dokument verdient sich seinen Platz, indem es ehrlich bleibt, was wir geprüft haben und was nicht.
Starten Sie einen Build und wollen das Testen abgesteckt, bevor Code live geht? Planen wir es gemeinsam.
Ein Logistikunternehmen, das in 190 Länder versendet, hat etwas gebaut, um an sich selbst zu liefern.
Eine Marke in ein funktionierendes Geschäft verwandeln.
Eine halbe Million Menschen. Eine App. Null Chaos.















