Warum Qualitätssicherung entwicklungsbasiert sein sollte Wenn Developer den eigenen Code testen

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Qualität in der Software-Entwicklung heißt, dass eine funktionale Anwendung die festgelegten Spezifikationen und Verwendungszwecke erfüllt. Die Verantwortung für die Qualität liegt aber nicht nur bei einzelnen Testenden, sondern beim gesamten Team und beim gesamten Unternehmen.

Das Testen isolierter Komponenten kann längst nicht mehr alle Probleme einer Anwendung aufdecken. Neue Funktionen, die perfekt abgedeckt sind, aber aufgrund eines serviceübergreifenden Vorfalls nicht funktionieren, sind an der Tagesordnung.

Im Zeitalter von Microservice-Architekturen und immer komplexeren verteilten Systemen stoßen wir immer häufiger auf diese Art von Problemen. Und eine der Möglichkeiten, ein wenig mehr Qualität zwischen den verschiedenen Bausteinen der Anwendungen zu gewährleisten, ist die Implementierung von Integrationstests und End-to-End-Tests (E2E).

Qualität liegt in der Verantwortung eines jeden. Wäre es in diesem Zusammenhang nicht besser, wenn die Entwicklerinnen und Entwickler auch High-Level-Tests schreiben könnten, um sicherzustellen, dass alle User die gewünschte Erfahrung machen?

Vorteile eines entwicklungsbasierten Testens

Einen Teil der Testautomatisierung an die Entwicklungsteams zu übertragen, bietet viele Vorteile. Einer der Hauptgründe ist die Beschleunigung der Entwicklung. Die Abdeckung der gesamten Testpyramide durch die Developer ermöglicht einen ganzheitlichen Ansatz beim Testen. Es reduziert die Einbindung einer dritten Partei in den Entwicklungsprozess und verringert die Duplizierung von Tests, die die Pipeline verlängert. Bei einem Integrationstest besteht zudem keinerlei Notwendigkeit, die Build-Kette mit einem E2E-Test zu überfrachten.

Die Abhängigkeit von einem engagierten Testing-Team reduziert die gefühlte Verantwortung innerhalb des Development-Teams. Dies kann zu einer „Nicht mein Problem“-Mentalität führen. Die Einbindung der Entwickler und Entwicklerinnen in die Durchführung der Tests hingegen ermöglicht es ihnen, die Verantwortung für den gesamten Lebenszyklus der Funktionalität zu übernehmen, und fördert die Verantwortung des Teams. Dies erhöht die Qualität des fertigen Produkts und fördert die Projekttreue.

Die Tatsache, dass das Testen keine Zusatzaufgabe ist, sondern Teil der Hauptaufgabe, stellt sicher, dass die Funktionalität vor der Bereitstellung wirklich abgedeckt ist. Darüber hinaus fördert es die Einführung der testgetriebenen Entwicklung (TDD) und trägt zur Wartbarkeit und Qualitätsverbesserung des Produkts bei.

Schon bei der Konzeption der Funktionalität wird die „Testbarkeit“ berücksichtigt. Dadurch lässt sich sicherstellen, dass die gelieferten Funktionen testbar sind. Dies hat auch den Vorteil, dass die Developer gezwungen sind, sich in die Lage der Nutzenden zu versetzen und über ihre Erfahrung nachzudenken. Tests können jederzeit von jedem und so oft wie nötig durchgeführt werden, was die Feedback-Schleife reduziert und den Entwicklungszyklus beschleunigt.

Eine Änderung der Denkweise ist notwendig

Developer sind im Allgemeinen nicht das beste Testpersonal, da sie immer glauben wollen, dass ihre Codes richtig funktionieren. Das ist eine schwierige Einstellung, und wenn man sich erst am Ende des Entwicklungsprozesses um das Testen kümmert, wird es mit Sicherheit zu Fehlern kommen. Aber es geht nicht darum, die Menschen allein zu lassen. Deshalb werden die Teams von Quality Coaches begleitet, die ihnen schon bei der Formulierung der Anforderungen helfen, auch über die Testbarkeit nachzudenken.

Heutzutage wird von den Entwicklungsteams verlangt, dass sie schnell und kontinuierlich neue Funktionen entwickeln. Die Entwicklungsgeschwindigkeit ist zu einem der Kriterien geworden, die darüber entscheiden, ob ein Team gut abschneidet oder nicht. Wird dieser Produktivitätswettlauf nicht richtig eingeordnet, kann er sich nachteilig auf die Softwarequalität auswirken.

An der Entwicklung beteiligte Fachkräfte empfinden das Testen oft als langweilig, repetitiv und kompliziert. Dennoch sind diejenigen, die Testreihen wiederholt durchführen können, für ein Team wertvoll. Langfristig gesehen verringert sich die Zahl der für Stakeholder und Product Owner sichtbaren Fehler, wenn Entwickelnde auch Tests schreiben.

Schlussfolgerung

Es ist wertvoll, wenn Developer ihren eigenen Code testen, schließlich kennen sie diesen besser als jeder andere. Das Testen ist nicht mehr wie früher ein Schritt im Entwicklungszyklus, sondern ein Teil der Entwicklungsphase.

Gleichzeitig ermöglicht dieser Ansatz ihnen, sich besser mit einer Anwendung und ihren Funktionen und Eigenheiten auseinanderzusetzen – und so auch zur Entwicklung neuer Funktionen beitragen zu können. Am Anfang wird es einige Zeit dauern, bis sich die Development-Teams eingearbeitet haben, aber später wird es sich auszahlen.

Dabei gilt es allerdings, das richtige Gleichgewicht zu finden. Im Zeitalter der Microservices kann ein Produkt aus mehreren Anwendungen bestehen, und wir können von den Entwicklerinnen und Entwicklern nicht verlangen, das gesamte Produkt zu beherrschen. Hier kommt der Mehrwert von Quality Coaches zum Tragen. Sie können Entwicklergemeinschaften in Bezug auf die Qualität der anwendungsübergreifenden Abläufe leiten, damit das Produkt als Ganzes ordnungsgemäß funktioniert.

Die Coaches sollten die Developer bei ihrem Qualitätsansatz auf der Anwendungsebene begleiten und ihnen helfen, sich weiterzuentwickeln, während sie gleichzeitig sicherstellen, dass das Gesamtprodukt weiterhin ordnungsgemäß funktioniert. Sie müssen sicherstellen, dass sie eine Anwendung liefern, die auch dann noch funktioniert, wenn sie mit den anderen Bausteinen des Produkts integriert wird.

* Guillaume Camus ist Quality Engineer bei ManoMano.

(ID:49258420)