Am Anfang meiner Karriere als Tester war ich Zeuge eines Gespräches zwischen zwei Entwicklern aus meinem Projekt. Der eine Kollege meinte, er sei fertig mit dem Ticket, müsse halt aber noch Tests schreiben. Das sagte er mit dem Gesichtsausdruck eines 9- Jährigen, der viel lieber draussen spielen gehen möchte als jetzt seine Hausaufgaben zu machen. Über Entwickler, die sich nicht motivieren können Tests zu schreiben, wurde an anderen Stellen bereits ausführlich diskutiert. Ich würde in diesem Blog gern auf das komplette Gegenteil eingehen: Entwickler, die gern und viele Tests schreiben. Was zunächst einmal wie ein Traum klingt, kann aber sehr schnell ins Gegenteil umschlagen. Ähnlich wie Schokoladensauce wohl portioniert etwas sehr Leckeres ist, ist zu viel davon schnell unangenehm. Analog dazu verhält es sich mit Entwicklertests. Häufig passiert es, dass sich dann eine Unmenge an Unit- und Integrationstests ansammelt, deren Inhalt und Fachlichkeit eigentlich niemand mehr durchschaut. In der Folge sind Entwickler dann mehr damit beschäftigt, fehlgeschlagene Tests zu analysieren, als sich um die Fachlichkeit ihres eigentlichen Tickets zu kümmern. Und genau damit fängt die Abwärtsspirale an, die bei Entwicklern eine gewisse Testmüdigkeit auslöst.
Damit stellt sich dann aber die Frage: Was ist das richtige Mass an Tests? Und die Antwort auf diese Frage ist wie so oft: Es hängt davon ab. Wichtiger als auf blosse Kennzahlen wie die Anzahl der Tests oder die Codeüberdeckung einzugehen, ist die Qualität der Tests. Lässt sich jedem Test eine(!) Fachlichkeit zuordnen oder sind teilweise nur technische Teilaspekte getestet worden, wie der Aufruf einer save-Methode auf dem Repository? Wenn zu sehr an der Technik und der Implementierung getestet wird, ist die Gefahr gross, dass die Verbindung zur eigentlichen Fachlichkeit verloren geht. Eine Implementierung kann sich ändern, z. B. durch den Austausch einer Datenbanktechnologie, aber die Fachlichkeit dahinter sollte davon unberührt bleiben. Wenn nun sehr viele «technische» Tests existieren, ist damit nun die Gefahr grösser, dass eigentlich fachneutrale Änderungen, wie z. B. Refactorings, plötzlich Tests fehlschlagen lassen und Alarmierungen auslösen, obwohl sich nichts am eigentlichen Feature geändert hat.
Die Herausforderung ist nun für die Entwickler eben wirklich gute Entwicklertests zu schreiben, die nicht zu stark an die Technologie gekoppelt sind und die Fachlichkeit adressieren. Das ist aber ein ziemlicher Paradigmenwechsel. Wie früher ist die Technik die Domäne der Entwickler, nun wird aber verlangt, dass sie bei den Tests eine fachliche Brille aufsetzen. Damit tun sich die Kollegen dann erfahrungsgemäss eher schwerer. Das ist auch kein Wunder, wird das Testen den Entwicklern leider nicht so intensiv vermittelt wie der Umgang mit Werkzeugen oder Softwarearchitekturen. Das ist jedoch problematisch, gerade vor dem Hintergrund der zunehmenden Bedeutung von Agilität, DevOps und Quality Engineering. Testaktivitäten wandern zunehmend auch in die Domäne der Entwickler, und deren Testaktivitäten werden essenziell für einen schnellen Projektfortschritt.
Testpyramide, Grafik von SwissQ
Es ist wichtig so früh wie möglich mit dem Testen anzufangen. Die Umsetzung der Testpyramide wird damit immer bedeutender für ein effektives und effizientes Testing. Dabei legen die Entwicklertests das Fundament, auf dem in den höheren Ebenen aufgebaut wird. Daher ist es entscheidend, dass dieses Fundament aus qualitativ hochwertigen Tests aufgebaut ist. Wenn der Umgang mit den Tests die Entwickler eher abschreckt mit diesen in Berührung zu kommen, dann wird eben jenes Fundament schnell brüchig. Damit ein stabiles und belastbares Fundament entsteht, ist es unabdingbar, dass Entwickler auch Kenntnisse und Fähigkeiten erlernen rund um das Thema Testing. Da kann man sehr früh im Entwicklungsprozess anfangen. Mehr Info dazu hier.
Wie kann die SwissQ ihr Unternehmen unterstützen?
Mit unserem neu geschaffenen Kurs «Entwicklungsnahes Testen» holen wir Entwickler genau dort ab, wo sie sich am wohlsten fühlen: an der Technik. In dem Kurs erarbeiten wir nicht nur, wie man Tests fachlich korrekt schneidet, sondern auch wie man die Testwerkzeuge von gängigen Tools und Frameworks wie SpringBoot oder Webdriver korrekt einsetzt. Es werden Methoden vermittelt, wie und wann man Mocks einsetzen sollte, wie man mit Testdaten innerhalb und zwischen Tests umgeht und was man besser mit Unittests und was besser mit Integrationstests abdeckt. Wir bieten seit neuestem ebenfalls Software Assessments an. Dabei werden Stärken und Schwächen in der Qualitätssicherung im gesamten Entwicklungsprozess identifiziert und Massnahmen abgeleitet. Wenn Sie mehr Infos dazu brauchen, zögern Sie nicht uns zu kontaktieren!
