Vor längerer Zeit habe ich als Product Owner mit einem Entwickler-Team zusammengearbeitet. Das Team entwickelte mit Java + Vaadin eine Webanwendung. Als sich die Probleme und Bugs häuften und auch teilweise wiederholten, erkundigte ich mich, ob zu den aufgetretenen Bugs auch dazugehörige Unit-Tests beim Beheben erstellt worden seien.
Für jeden Bug ein Unit-Test
Das Prinzip, für jeden Bug einen Unittest zu schreiben, hat den Zweck, sogenannte Regressions zu verhindern. Damit ist gemeint, dass ein Bug in der Zukunft wieder auftaucht und erneut behoben werden muss.
Meine Frage wurde vom Teamlead verneint und mit „Wir machen Frontend-Entwicklung, da kann man keine Unit-Tests schreiben“ begründet. Ich gebe zu, dass ich sprachlos war und keine ausreichenden Gründe finden konnte, um diesen Glaubenssatz zu widerlegen.
Bevor ich es vergesse, sei noch die zweite Begründung erwähnt, nämlich „Wir machen Datenbankabfragen, dafür können wir keine Unit-Tests schreiben“.
Da die auftretenden Probleme die mir vorgegebene Deadline gefährdeten (dabei half es auch nicht, dass das Team meinem Projekt erst 2 Monate später zugewiesen wurde, ohne die Deadline anzupassen), drängte ich darauf, dass wir dann wenigstens Frontend-Tests machen sollten (mit Selenium).
Wir brauchen einen externen Tester
Ich konnte mich durchsetzen (zu welchem Preis?) und erreichte, dass dem Team ein externer Tester zugewiesen wurde. In den ersten 2-3 Wochen lief es tatsächlich gut und es wurden einige Tests geschrieben. Dann aber häuften sich die Stories, die nicht abgeschlossen waren sondern auf „In Test“ standen. Völlig überraschend stellte sich heraus, dass ein Tester nicht mit dem Testen hinterherkommt, wenn das Team aus 5 Entwicklern besteht.
Eine weitere Erkenntnis für mich war, dass die Entwickler dadurch ihren eigenen Code zwar schrieben, aber selber keine Tests mehr machten („Dafür haben wir doch den Tester…“). Dies führte dazu, dass sehr viele Stories wieder zurück zu den Entwicklern gingen und dazu führten, dass es noch mehr für den Tester zu tun gab.
Als im Backlog die Zahl der Bugs auf über 300 stieg, kam der Vorschlag aus der Entwicklung, einfach alle Bugs zu löschen, weil das wären so viele, die könne man nicht mehr beheben.
Das ist doch alles erfunden
Leider ist das tatsächlich so passiert, auch wenn ich vielleicht mit den genauen Zahlen nicht mehr korrekt unterwegs bin. Vielleicht waren es 3-4 Wochen und 4 statt 5 Entwickler, da bin ich nicht mehr so sicher.
Und jetzt?
Heute hatte ich die Gelegenheit mal wieder ein bischen Code zu einem unserer Projekte beizutragen. Und dabei ist mir aufgefallen, dass ich genau das, was ich immer wieder anspreche, selbst nicht getan habe. Nämlich zu meinem Code auch passende (und sinnvolle) Unit-Tests zu schreiben.
Test First oder Disziplin
Eine gute Testabdeckung ist mir weiterhin wichtig. Ich sehe dafür zwei Wege, entweder stelle ich mich um und gewöhne mir an, zuerst meine Tests zu schreiben (wie es auch z.B. Robert C. Martin vorschlägt) oder ich zwinge mich, diszipliniert direkt im Anschluss meine Tests zu erstellen. Für meinen eigenen Code ist genau eine Person verantwortlich, nämlich ich selbst. Und wenn ich meinem Anspruch an mich selbst und die Qualität meiner Arbeit genügen will, darf ich hier nicht lockerlassen – und sei es noch so verlockend, in den Feierabend zu gehen.