Lass Entwickler die erste Testinstanz sein

Fünf Minuten Entwicklerzeit können den entscheidenden Unterschied machen

Hier ist eine einfache, aber wirkungsvolle Strategie: Lass Entwickler gegenseitig ihren Code testen, bevor er bei den Testern landet. Das reduziert offensichtliche Bugs, gibt Testern Zeit, sich auf komplexe Probleme zu konzentrieren, und verringert den administrativen Aufwand für die Nachverfolgung von Problemen.

Zum ersten Mal habe ich das vor Jahren umgesetzt, als ich die Testaktivitäten für ein Unternehmen leitete, das Entwicklungsteams für individuelle Software stellte. Die Herausforderung? Die Kunden wollten in der Regel nur für Entwickler bezahlen, nicht für Tester. Ich musste also Entwickler im Testen coachen und einen Testprozess aufbauen, der zu ihrem Arbeitsablauf passte. Das Team war grossartig, und die Ergebnisse waren aufschlussreich!

Die Änderung, die den grössten Unterschied machte? Eine einfache Regel: Bei jedem Pull Request mussten die Entwickler zwei Dinge tun – ein Code Review und einen kurzen manuellen Test des neuen Codes ihres Kollegen, bevor irgendetwas in den Main Branch ging. Das Ziel war nicht, stundenlang zu testen. Als Faustregel sollten die Entwickler stattdessen fünf Minuten investieren, um die Grundlagen zu prüfen und mit ihrer Intuition und ihrem Wissen offensichtliche Mängel zu erkennen. Wenn sie doch mehr als fünf Minuten testeten, dann weil sie etwas gefunden hatten, das später im Prozess viel mehr Zeit sparte.

Das ist passiert:  

1. Offensichtliche Probleme wurden früh entdeckt – genau wie Tippfehler, die wir in unseren eigenen Texten alle übersehen, die anderen aber sofort auffallen. Das schaffte Zeit, die vorher in die Bug-Administration geflossen war, weil sich ein Fix direkt vor der Auslieferung erstellen liess.  

2. Die Zusammenarbeit verbesserte sich enorm. Statt sich hinter ihrem Code zu verstecken, diskutierten die Entwickler offen über Features, Anforderungen und alternative Lösungen. Diese Gespräche führten zu besseren Designs, klareren Spezifikationen und sogar zu schnellerer Entwicklung.

Meine ursprüngliche Theorie war, dass die Entwickler ihre Arbeit doppelt prüfen würden, um nicht schlecht dazustehen, weil der Kollege am Platz nebenan sie testen würde. Aber so kam es nicht! Was ich nicht erwartet hatte, war, wie sehr diese kleine Zeitinvestition Raum für einen echten Dialog schuf. Unter Lieferdruck lassen Teams solche Diskussionen nicht selten aus. Indem wir eine Pause zum Testen vorschrieben, lösten wir eine Zusammenarbeit aus, die Wissen verbreitete, Prioritäten aufeinander abstimmte und das Team zusammenschweisste. Am Ende ging es nicht mehr darum, nicht schlecht dazustehen, sondern darum, gemeinsam etwas Grossartiges zu schaffen.  

Diese Ergebnisse konnte ich in einer anderen Entwicklungsorganisation wiederholen, in der ich einen mehrtägigen Workshop durchführte. Dort teilten sich mehrere Entwicklungsteams ein paar wenige Tester, die mit einfachen, offensichtlichen Bugs überlastet waren und keine Zeit für tiefergehendes Testen hatten. Sobald die Entwickler den ersten Test übernahmen, konnten sich die Tester auf das konzentrieren, was sie am besten können: mit ihren Fähigkeiten im Testdesign komplexe Probleme aufdecken. Ausserdem wurden manche Probleme, für die es technisches Fachwissen über den Code braucht, jetzt früh entdeckt. Die Rückmeldung war, dass dies die wirkungsvollste Änderung war, die sie je an ihrem Entwicklungsprozess vorgenommen hatten, obwohl sie zu den günstigsten gehörte.

Und doch scheinen sich überraschend viele Organisationen gegen diese Arbeitsweise zu sträuben, obwohl zahlreiche moderne Entwicklungsansätze, von Extreme Programming bis zu verschiedenen agilen Praktiken, Ähnliches propagieren. Ich hatte einmal eine hitzige Debatte mit einem Entwicklungsleiter, der darauf bestand, dass Entwickler ihren Code nicht testen sollten, NIEMALS! Das Projekt dümpelte acht Monate lang vor sich hin, gefangen in einem Kreislauf, in dem der Trend der kritischen Bugs nie gegen null zeigte. Am Ende wurde das Projekt auf einen Bruchteil seines ursprünglichen Umfangs zurückgefahren, um überhaupt ausliefern zu können.  

Warum funktioniert das?

• Ein frischer Blick entdeckt, was du vielleicht übersiehst. Tunnelblick ist normal – wir sind alle nur Menschen.
• Entwickler haben spezifisches Fachwissen. Manche Probleme finden Entwickler, die die technischen Aspekte des Codes genau kennen, einfach effektiver.  
• Zusammenarbeit gedeiht, wenn du ihr Raum zum Atmen gibst. Beim Fünf-Minuten-Test geht es nicht nur um Bugs – er ist eine Chance, Anforderungen zu besprechen, Wissen zu teilen und sich auf gemeinsame Ziele abzustimmen.  

Das Fazit lautet also: Lass Entwickler die erste Testinstanz sein. Es ist eine günstige Umstellung mit grosser Wirkung, die die Qualität verbessert, Tester entlastet und das Kopfzerbrechen mühsamer Bug-Administration reduziert. Und als Bonus? Vielleicht arbeitet dein Team auf einmal besser zusammen.  

Probier es aus. Schon fünf Minuten können die Qualität und die Zusammenarbeit in deinem Team grundlegend verändern.