und ähnliche. Sicher sehen viele darin nichts Übles – das betrifft sowohl die Fragesteller als auch die Tester, Implementierer und Programmierer. Aber wenn man genauer über diese Fragen nachdenkt, kann man zu ganz anderen Schlussfolgerungen kommen.
Stellen wir uns vor, dass gleich nach der Eingabe des Codes in den Produktionsserver eine Störung auftritt. Die für die Implementierung verantwortliche Person stellt die magische Frage in den Raum: „Wer hat das getestet?“ Der erste und wichtigste Punkt ist – sollte diese Frage in dieser Situation überhaupt gestellt werden? Ist es in diesem Moment am wichtigsten, wer getestet oder das Code-Review gemacht hat? Die Antwort ist – nein. In dieser Situation ist es am wichtigsten, die Störung zu beheben. Erst danach kann man darüber nachdenken, warum es uns nicht gelungen ist, den Defekt früher zu lokalisieren. Ich betone – nachdenken, nicht fragen: „Wer hat das getestet?” Ich habe den Eindruck, dass wir uns zu oft darauf konzentrieren, einen Schuldigen zu finden und damit die Mitverantwortung für die Störung von uns abzuwenden.
Teamkommunikation ist der Schlüssel
Aber das ist wohl nicht der richtige Weg. Nicht genug, dass wir das Problem nicht finden, wir können so noch eine Reihe anderer verursachen. Was meine ich damit? Die Leute sind verschieden und dieselbe Mitteilung kann verschieden aufgefasst werden. Der eine lässt eine so gestellte Frage unbeachtet. Der nächste kann sie sehr persönlich nehmen, was dazu führen kann, dass die Person den Glauben an sich verliert, vor der Arbeit mit der betreffenden Person Angst bekommt, und noch andere Konsequenzen haben kann. Es muss klargestellt werden, dass die Anschuldigung einer Person im Team vollkommen ungerechtfertigt ist. Schließlich wurde die betreffende Funktionalität vorher von jemandem beschrieben, von jemand anderem kodiert, dann wurden Tests und vielleicht auch ein Code-Review durchgeführt. Es ist möglich, dass so ein fehlerhafter Code durch das dichte Sieb der automatischen Tests geschlüpft ist. Der wesentliche Punkt ist, dass etwas schlecht realisiert wurde, und nicht, wer den Fehler gemacht hat. Das Problem steckt sicher nicht im Menschen allein, sondern in unserem Prozess oder vielmehr in dessen Unzulänglichkeiten.
Zielfehler?
Es sei denn, wir haben einen Saboteur unter uns. Ich glaube nicht, dass in unserer Branche irgendwer seine Arbeit absichtlich schlecht macht – ich glaube, das Problem ist im Prozess zu suchen. Zum Beispiel wurde die Aufgabe nicht ausreichend beschrieben oder der Testumfang wurde falsch festgelegt. Vielleicht hat der Programmierer vergessen, dem Tester zu sagen, dass die Änderungen, die er eingeführt hat, nicht nur das Modul A betreffen, sondern auch das Modul B? Oder, dass Regressionstests unerlässlich sind? Oder vielleicht ist der Tester – überzeugt von seinem großen Wissen über das getestete System – davon ausgegangen, dass er über alle notwendigen Informationen zum Testen der betreffenden Änderung oder Funktionalität verfügt und sich nicht weiter beim Programmierer erkundigt hat? Mögliche Ursachen gibt es viele, dennoch bin ich davon überzeugt, dass man die meisten davon durch eine verbesserte Kommunikation vermeiden kann.
Problem liegt meistens nicht beim Menschen
Wir dürfen nicht vergessen, dass wir – unabhängig von dem Verfahren mit dem wir arbeiten – alle in derselben Mannschaft spielen. Wir haben ein gemeinsames Ziel, spielen auf dasselbe Tor. Bringen wir mit der Frage „Wer hat das getestet?” unser Team zusammen oder verursachen wir damit eine Auflösung der Beziehungen und die Zerstörung des gegenseitigen Vertrauens? Ich wiederhole – das Problem liegt meistens nicht beim Menschen, sondern im Verfahren. Finden wir das Problem und nicht den „Schuldigen“. Nur so verbessern wir die Qualität unseres Produkts und unserer Arbeit, nur so schaffen wir eine gute Atmosphäre. Denken wir daran – jeder kann sich irren. Nicht nur der Programmierer kann einen schlechten Tag haben und einen Fehler machen, auch der Tester kann etwas übersehen oder vergessen. Wir sind alle nur Menschen und machen Fehler, das ist nicht zu vermeiden. Aber unsere Arbeit müssen wir so organisieren, dass solche Fehler vermieden werden und so selten wie möglich geschehen.
