Diese Aussage habe ich noch vor einigen Jahren öfter benutzt. Die Argumentation war, dass Entwickler ja die zu entwickelnde Applikation kennen und deshalb immer nur das testen, was auch funktioniert. Wer mich kennt weiß, dass ich heute eine ganz gegenteilige Meinung habe. Aber warum?

Testen ist ein elementarer Teil der Softwareentwicklung. So wie es niemandem einfallen würde einen nicht kompilierten C# Code an einen Kunden auszuliefern würde auch niemand eine ungetestet Software ausliefern. Jeder Entwickler testet deshalb auch den ganzen Tag. Alle paar Minuten (oder spätestens nach ein paar Stunden) wird wieder die neue Funktionalität getestet. Nur leider machen die wenigsten Entwickler das systematisch. Die Software wird gestartet und die neue Funktionalität wird “ausprobiert”. Die Informationen, wie der Entwickler die Funktionen testet gehen dabei völlig verloren. Da nichts dokumentiert wird und das Testen eine langweilige, wiederkehrende Aufgabe ist (die Entwickler von Grund auf hassen) wird mit dem erneuten Testen nach einer Änderung auch eher schlampig umgegangen (“Daran hab ich doch gar nichts geändert.”). Die Aussage, dass Entwickler schlechte Tester sind ist also gar nicht so falsch. Aber: um gute Software zu liefern müssen Entwickler gute Tester werden!

Um einen guten, wartbaren und evolvierbaren Code zu erhalten muss die Codebasis durch UnitTests abgedeckt sein. Ich denke jeder wird mir zustimmen, dass das Schreiben von UnitTests eine Aufgabe für Entwickler ist. UnitTests stellen also die Basis dar, dass das Verhalten von Softwaremodulen systematisch, automatisch und wiederholbar getestet werden kann.

Wenn die “Unit” erstellt wurde muss sie in das bestehende System integriert werden. Hier ist es nötig Integrationstests durchzuführen. Dies sind Aufgaben die auch wieder und wieder ausgeführt werden müssen nach jeder neuen Integration müssen sie erneut ausgeführt werden. Es empfiehlt sich also auch diese Tests zu automatisieren. Wie ist in erster Linie egal – aber automatisiert sollten sie werden. Die Automatisierung stellt sicher, dass die Tests viel öfter und unabhängig von der Person ausgeführt werden. Und natürlich ist Automatisierung eine Entwickleraufgabe…

Und Akzeptanztests? Wer schreibt den die? Akzeptanztests sind da um sicherzustellen, dass alle Anforderungen vom Kunden erfüllt sind. Jetzt wäre es natürlich wünschenswert, dass der Kunde diese Tests am besten selber schreibt und den Entwicklern zur Verfügung stellt. Das sehe ich in der Praxis leider selten, da die wenigsten Kunden dazu in der Lage sind. Der Kunde kauft von uns ein Produkt und hat kein Interesse daran ein Spezialist für Softwareentwicklung zu werden. Deshalb muss jemand von uns die Testfälle schreiben und der Kunde nicht sie nur ab. Warum denn nicht der Entwickler? Wer kennt die Anforderungen im Moment der Umsetzung besser als der Entwickler? Wer kennt den die ganzen kleinen Entscheidungen, die nirgends definiert werden? Ob zum Beispiel die Funktionalität über einen Button, einen ImageButton oder einen LinkButton aufgerufen wird. Oft ist das ja gar nicht definiert. In diesem Fall sind die Entwickler am besten in der Lage reproduzierbare Testfälle zu schreiben. Und das Vieraugenprinzip? Ich glaube das ist eher eine Ausrede sich von dem Testing zu drücken. Das Vieraugenprinzip kann auch durch einen Review durch ein anderes Teammitglied erfolgen. Außerdem muss ja eh der Kunde die Tests freigeben.

Und bitte versteht mich nicht falsch: das Testen innerhalb des Entwicklungsprozesse ersetzte nicht eine zusätzliche Qualitätssicherung durch die QS. Diese kommt obendrauf. Ebenso kommen ja auch noch Performance- und Lasttests dazu. Von diesen habe ich ja auch noch nicht gesprochen.

Die (meisten) Entwickler sind schlechte Tester. Wenn wir das ändern werden wir bessere Software mit weniger Fehlern am Ende eines Sprints ausliefern.