Minimum-Viable-Teststrategie

Eine Minimum Viable Teststrategie ist ein kollaborativ erarbeiteter, leichtgewichtiger Einstieg ins Testen: keine hundert Seiten Dokument, sondern eine gemeinsame Landkarte aus Teststufen, Testarten, Rollen, Tools, Umgebungen und Metriken. Sie schafft ein geteiltes Verständnis, benennt offene Punkte als Backlog-Items und gibt Teams sofort etwas, womit sie loslegen können.

Das Wichtigste in Kürze

• Eine Minimum Viable Teststrategie entsteht nicht durch Dokumente, sondern durch kollaborative Workshops, die ein gemeinsames Testbild schaffen, mit dem Teams sofort loslegen können.
• Teststufen wie Microservice-Ebene oder Produktebene müssen im Kontext der eigenen Architektur neu definiert werden, weil klassische Stufenmodelle für moderne Systemlandschaften oft nicht passen.
• Der gefährlichste Moment in einem Teststrategie-Workshop ist schnelle Einigkeit, nicht Streit: Wer zu früh zustimmt, überspringt Lücken, die später teuer werden.
• Nicht-funktionale Anforderungen wie Security oder Performance werden in agilen Projekten systematisch nach hinten verschoben, obwohl das Risiko bewusst entschieden und dokumentiert sein sollte.
• Eine Tabelle aus Teststufen, Testarten, Rollen, Tools, Umgebungen und Metriken macht Widersprüche sichtbar, die beim Lesen langer Teststrategiedokumente unbemerkt bleiben.

Was eine Minimum Viable Teststrategie ist

Eine Minimum Viable Teststrategie ist ein leichtgewichtiges, gemeinsam erarbeitetes Grundgerüst, mit dem Teams sofort testen können, ohne auf ein fertiges Dokument zu warten. Der Begriff lehnt sich an das Minimum Viable Product an. Statt einer ausformulierten Strategie entsteht ein Startpunkt, der bewusst Lücken zulässt und über die Zeit wächst.

Der Unterschied zur klassischen Variante ist die Haltung. Eine klassische Teststrategie wird von ein, zwei Leuten über Wochen geschrieben, manchmal über Jahre abgestimmt, und am Ende liest sie keiner. Eine Minimum Viable Teststrategie liefert dagegen das gemeinsame Verständnis, mit dem Teams loslegen, plus ein Backlog für die offenen Punkte.

Kathrin Potzahr fasst das Ziel so: nicht das vollständige Konzept, sondern genug, um in einen kontinuierlichen Lernprozess zu kommen. Wenn nichts da ist, kann niemand kontinuierlich verbessern. Mit einem ersten Stand schon.

Warum die klassische Teststrategie an der neuen Welt scheitert

Klassische Teststrategien passen schlecht in moderne Architekturen, weil sie aus einer anderen Welt stammen. Ein typischer Fall: Ein Programm soll von monolithischen Applikationen auf Microservices, Cloud und agile Entwicklung umstellen. Die alte Welt ist gut beschrieben, für die neue weiß niemand, wie getestet werden soll.

Das Problem zeigt sich schon bei den Teststufen. Wer aus der alten Denkweise kommt, sieht zuerst Applikationen als Testebene. Im Microservice-Kontext ist aber der Service die Deployment-Einheit und muss als solche abgesichert werden. Daneben braucht es eine Produktsicht, weil ein Produkt aus mehreren Services zusammengesetzt sein kann.

Hinzu kommt die Legacy-Welt, die nicht verschwindet. Umsysteme, die nur zweimal im Jahr deployed werden, hängen weiter an den neuen Services. Eine gute Teststrategie muss beide Welten nebeneinander sichtbar machen, statt so zu tun, als gäbe es nur die neue.

Wie ein Teststrategie-Storming abläuft

Teststrategie-Storming überträgt die Idee des Eventstorming auf die Teststrategie: ein kollaborativer Workshop mit Post-its statt eines einsam geschriebenen Dokuments. Das Format ist bewusst leichtgewichtig und entsteht im Raum, nicht in der Vorbereitung.

Den Kern bildet eine Tabelle als Testlandkarte. Die Achsen sind Teststufen und Testarten, die Zellen werden mit Zetteln gefüllt: verantwortliche Rollen, Tools, Umgebungen, Metriken. Wo Wissen fehlt, kommt ein Zettel mit offenem Punkt dran. So entsteht aus dem Workshop kein fertiges Konzept, aber eine klare Sicht darauf, wo es hakt.

In der Praxis reichten dafür drei aufeinanderfolgende Workshops. Wichtig ist, dass nicht mit vorgefertigten Karten gestartet wird, sondern mit einer leeren Tabelle. Die erste Frage lautet schlicht: Welche Teststufen brauchen wir? Der erste Eintrag ist meist ein No-Brainer wie Unit Testing, danach beginnt die eigentliche Diskussion.

Diskussion ist das Ergebnis, nicht das Hindernis

Die Reibung im Workshop ist kein Zeitverlust, sondern der eigentliche Wert. Beim Versuch, Service und Produkt voneinander abzugrenzen, entstehen lange Diskussionen. Die genaue Definition ist dabei zweitrangig. Es geht darum, dass alle Beteiligten ein gemeinsames Bild davon bekommen, was eine Deployment-Einheit ist und was auf Produktebene gehört.

Auch formale Einordnungen müssen nicht stimmen, solange das Team zufrieden ist. Consumer-Driven-Contract-Tests lassen sich als Testart begründen, weil sie Interoperabilität prüfen. Wenn die Beteiligten sie lieber als Teststufe führen, bleibt das so stehen. Maßgeblich ist das gemeinsame Verständnis, nicht die korrekte Schublade.

Genau hier liegt eine überraschende Gefahr. Riskanter als endloses Verzetteln ist, dass sich ein Team zu schnell einigt.

Ich glaube, es ist viel gefährlicher, dass sich die Leute schnell einigen, als dass sie sich nicht einigen.

Kathrin Potzahr

Warum der Moderator Teststrategie können muss

Ein Teststrategie-Storming braucht eine Moderation, die selbst vom Testen kommt, weil ihre Hauptaufgabe das Hinterfragen ist. Wer nur durch die Agenda führt, lässt vorschnelle Einigungen durchgehen. Wer das Thema versteht, pikst nach: Fehlt euch nicht noch etwas? Ist das wirklich so, oder kommt das nur aus der alten Welt?

Diese Challenge-Funktion wiegt schwerer als Tempo. Der Reflex vieler Moderatoren, möglichst schnell durchzukommen, geht am Ziel vorbei. Sinnvoller ist, breit zu denken und die Landkarte vollständig zu bekommen. Kleiner und konkreter wird sie später ohnehin, in den einzelnen Tasks.

Wenn ein Team sich doch in Kleinigkeiten verliert, hilft klassisches Moderationshandwerk: abschließen, einen Zettel mit offenem Punkt kleben, weitermachen. Die Detaildiskussion lässt sich vertagen, ohne dass die Information verloren geht.

Die richtigen Leute entscheiden über das Ergebnis

Ein Teststrategie-Storming funktioniert nur mit den passenden Teilnehmern, und wer das ist, lässt sich nicht von außen vorschreiben. Genau wie beim Eventstorming hängt der Wert an der Besetzung. Agile Projekte kennen oft nur Entwickler, Scrum Master und Product Owner. Große Programme haben mehr Rollen, die beteiligt sein müssen.

Eine feste Regel gibt es nicht, aber zwei Konstanten. Die Teams, die die Testarbeit später leisten, müssen über Repräsentanten vertreten sein. Und idealerweise sitzt jemand mit Produktbrille am Tisch. In ein Workshop mit hundert Personen gehören die Teams nicht vollständig, sonst kippt das Format.

Eine bewährte Besetzung umfasste Architekten, Testmanager, Betrieb und Sicherheitsexperten. Je nach Kontext kommen Projekt- oder Programmmanager dazu, Leute aus der Build-Infrastruktur oder in einem skalierten Umfeld ein System-Team. Das eine Kernrezept existiert nicht. Die Beteiligung der Teams ist nicht verhandelbar.

Diese Komponenten gehören in die Landkarte

Die Testlandkarte besteht aus zwei Achsen und vier Inhalts-Ebenen je Zelle. Teststufen und Testarten spannen das Raster auf, die Zellen füllen sich mit Rollen, Tools, Umgebungen und Metriken.

Bei den Rollen entscheidet sich, ob die Strategie trägt. Wenn die Landkarte selbst noch offene Arbeit enthält, muss klar sein, wer diese Arbeit einsteckt. Sonst bleibt das Backlog ein Wunschzettel ohne Adressaten.

Die Testarten sind meist der stabilere Teil, weil sie sich beim Architekturwechsel kaum ändern. Trotzdem lohnt das Challengen: Ist Robustheit eine eigene Testart oder Teil der Funktionalität? Läuft Wartbarkeit separat oder unter den Unit-Tests mit? Diese Fragen schärfen das gemeinsame Bild.

Metriken und Zielwerte gehören ans Ende, nicht an den Anfang

Eine Minimum Viable Teststrategie nennt zuerst die Metrik, nicht den Zielwert. Es reicht festzulegen, dass Code Coverage gemessen werden soll. Ob 80, 75 oder 90 Prozent richtig sind, ergibt sich später aus der Erfahrung.

Das ist kein Aufschieben, sondern Methode. Man startet mit einem Wert, beobachtet, ob es Probleme gibt, und justiert nach. Vielleicht passen in einem Fall 90 Prozent und in einem anderen 75. Ohne ersten Stand fehlt die Grundlage für genau diese Verbesserung.

Wo die Anforderungen noch nicht klar genug sind, etwa bei Last und Performance, gehört der Punkt offen markiert. Erst die Anforderungen klären, dann die Metrik daraus bauen. Das ehrlich als offenen Punkt zu führen ist besser, als eine Scheinpräzision aufzuschreiben.

Nicht-funktionale Anforderungen rutschen sonst nach hinten

Eine sichtbare Landkarte schützt die nicht-funktionalen Anforderungen davor, vergessen zu werden. In agilen Projekten konzentrieren sich Teams stark auf Features und schieben Security, Performance oder Usability nach hinten. Das passiert nicht aus Unwissen, sondern aus Fokus.

Bewusstes Verschieben ist legitim, unbewusstes ist gefährlich. Wer weiß, dass sicherheitsrelevante Anforderungen existieren, kann entscheiden: für das MVP mit kleinem Nutzerkreis noch nicht kritisch, später unverzichtbar. Drei Sprints mit Bibliotheken voller Sicherheitslücken sind verkraftbar, wenn das Produkt erst nach zwanzig Sprints live geht. Der Punkt ist, dass die Entscheidung bewusst fällt.

Genau dafür hilft die Visualisierung. Sie hält die nicht-funktionalen Eigenschaften präsent, auch wenn sie in den Teststufen erst spät zum Zug kommen.

Von der Landkarte zu Backlog-Items

Nach dem Workshop wird die Landkarte den Teams gezeigt, und aus den offenen Punkten werden Backlog-Items. Die große Tabelle mit Post-its ist nicht Hochglanz, aber gut nachvollziehbar. Teams sehen, wo sie beteiligt sind und was von ihnen erwartet wird.

Auch wer im Workshop nur über Repräsentanten vertreten war, kann hier noch Wünsche und Änderungen einbringen. Danach kennen die Teams ihre Aufgaben. Die offenen Zettel werden zu konkreten Backlog-Items, die jemand weitertreiben muss.

In einem Fall übernahm das eine Architekten-Gilde. Sie nahm das Test-Thema als ihre Aufgabe, trug es in die Teams und setzte es in den Pilotprojekten um. Eine ausformulierte Teststrategie entsteht in formaleren Umfeldern später trotzdem. Die Hoffnung ist nur, dass sie gelebt und angepasst wird, statt als hundert ungelesene Seiten zu enden.

Visualisierung deckt auf, was im Fließtext verborgen bleibt

Die Testlandkarte funktioniert auch ohne großen Workshop, als Werkzeug, um bestehende Teststrategien zu prüfen. Lange Dokumente lassen sich in das gleiche Raster übertragen, und dabei fällt auf, was beim Lesen unsichtbar bleibt.

Ein Beispiel: Ein Projekt hatte zwei Teststrategien, eine für den Akzeptanztest und eine für die Stufe davor. Erst die Übertragung in die Visualisierung machte die Brüche sichtbar. Unterschiedliche Begrifflichkeiten, teils gegensätzliche Ziele, alles, was sich über die Seiten verteilt verbirgt.

Das ist der wiederverwendbare Kern der Methode. Die Landkarte zwingt verstreute Aussagen in eine Struktur, in der Widersprüche nicht mehr durchrutschen. Ob für eine neue Strategie oder die Inventur einer alten, das Bild zeigt mehr als der Text.