Eine gute Teststrategie passt auf eine Seite

Dieser Satz hat mich nicht mehr losgelassen. Nicht weil er neu war, sondern weil er genau beschreibt, wie ich arbeite.

Ich habe in Projekten gearbeitet, in denen Testkonzepte mit über 50 Seiten keine Seltenheit waren. Irgendwann hatte das Dokument so viel mit der Realität des Projekts zu tun wie ein Stadtplan von 1987 mit dem heutigen Straßennetz.

Das muss nicht so sein.

Gemeinsam statt alleine

Eine Teststrategie alleine zu schreiben funktioniert nicht. Ich kann sie nur nach meinem eigenen Verständnis formulieren — und ich weiß mit Sicherheit, dass ich nicht alles wissen kann. Das Team weiß mehr als ich alleine.

Deshalb erarbeite ich die Strategie gemeinsam mit dem Team. Mit Methoden wie Risk Storming sprechen wir darüber, welche Risiken wirklich wichtig sind — und welche Testmethoden uns helfen, diese Risiken zu minimieren. Das Ergebnis landet auf einem Flipchart-Blatt.

Vier Fragen. Für alle sichtbar:

• Was testen wir?
• Was testen wir nicht?
• Wie machen wir das?
• Wer ist dabei — und was brauchen wir dafür?

Was dabei passiert

Wenn ein Team diese Fragen gemeinsam beantwortet, ist das erste Ziel schon erreicht: Alle wissen, worauf wir uns in den nächsten Wochen fokussieren — und was wir bewusst weglassen. Es entsteht Klarheit und Transparenz. Und meiner Erfahrung nach entsteht dabei auch ein Wir-Gefühl — kein "Entwickler gegen Tester" mehr.

Kein agiles Vorrecht

Das funktioniert in jedem Projekt — egal ob Scrum, Wasserfall oder V-Modell. Auch ein klassisches Setup verbietet mir nicht, meine Strategie unterwegs anzupassen.

In einem meiner Projekte haben wir genau das erlebt. Wir haben anfangs versucht, am Ende Qualität "reinzutesten". Das hat zu Frustration geführt — Abweichungen wurden spät entdeckt, Qualität wurde zum Schlussthema. Wir haben die Strategie im laufenden Projekt umgestellt: Das Know-how der Tester kam direkt zu den Entwicklern. Plötzlich haben wir mit zwei Sichten gearbeitet, die sich ergänzt haben — Entwickler die wussten wie man guten Code schreibt, und Tester die erste Ergebnisse schon während der Entwicklung prüfen konnten. Viel früher, viel besser.

Sichtbar schlägt ausführlich

Ein Flipchart im Raum lebt. Es kann diskutiert werden. Es kann sofort angepasst werden, wenn sich etwas ändert. Ich wiederhole den Prozess in regelmäßigen Abständen — nicht um ein Dokument zu pflegen, sondern um zu prüfen ob wir noch in die richtige Richtung testen.

Manche Teams beschreiben genau diese Punkte in ihrer Definition of Done. Die lebt. Wird angepasst. Verstaubt nicht.

Der erste Schritt

Wenn dein Team noch nie über Teststrategie gesprochen hat — fang klein an. Ein Risk Storming oder ein TQR-Workshop liefern sehr gute Ideen für den richtigen Einstieg. Es gibt unterschiedliche Startpunkte. Wichtig ist nur, dass ihr gemeinsam anfangt.

Ein Blatt reicht.