Sollten Entwickler selber testen?

"I dont always test my code...But when I do, I do it in production!" 

Lesezeit ca 6 Minuten

Warum die Qualitätssicherung (QA) oder das Softwaretesten nicht ausschließlich von Entwicklern durchgeführt werden sollte 

Die Frage, ob die Qualitätssicherung (QA) von einem Entwickler übernommen werden sollte, ist eine der häufigsten in der Softwareentwicklung. Viele Unternehmen und Teams stehen vor der Entscheidung, ob sie eine dedizierte QA benötigen oder ob die Entwickler selbst für die Qualitätssicherung verantwortlich sein können.

Ein weit verbreiteter Ansatz ist, auf eine separate QA zu verzichten und stattdessen die Entwickler für das Testen ihrer eigenen Software zu beauftragen. Dieser Ansatz wird oft aus Gründen wie zb. begrenzten Ressourcen oder finanziellen Engpässen gewählt. Doch ist es wirklich ratsam, die QA ausschließlich den Entwicklern zu überlassen? Oder sogar einem Projektmanager oder Product Owner die Abnahme seiner definierten Features zu überlassen?

Im ersten Blogbeitrag "Brauche ich wirklich eine QA?" haben wir bereits über die Bedeutung einer dedizierten QA gesprochen. Hier möchten wir tiefer in die Vor- und Nachteile dieses Ansatzes eintauchen, um euch bei der Entscheidungsfindung zu helfen.

Warum Entwickler ihre eigene Software nicht testen sollten

Betriebsblindheit

"Not seeing the wood for the trees” ( german phrase )

Entwickler sind oft zu nah an ihrem eigenen Code, um Fehler objektiv zu erkennen. Sie neigen dazu, Fehler zu übersehen, die für andere Nutzer offensichtlich erscheinen mögen und schlimmstenfalls schwerwiegend sein können. 

Ein passendes Beispiel hierfür wäre die Metapher des vorherigen Blogs: Schreibt einen Text auf ein Blatt Papier und kontrolliert ihn auf Fehler. Anschließend bittet eine zweite Person, den Text zu korrigieren. Diese Person wird sicherlich Fehler finden, die ihr übersehen habt.

Erfolgsfall

“The acceptance criteria are met, so it's successful, for sure!”

Entwickler testen normalerweise ihre Software unter idealen Bedingungen, um sicherzustellen, dass sie wie erwartet funktioniert. Sie neigen dazu, weniger Zeit damit zu verbringen, negative Szenarien oder unerwartete Nutzungsszenarien zu berücksichtigen. 

Dieses sogenannte Happy-Path-Testing ist natürlich ein Bestandteil der Qualitätssicherung, jedoch nur ein kleiner Teil davon. Der Großteil der Arbeit besteht aus dem Testen von negativen Szenarien und dem Umgang mit Fehlern. Ein Tester versucht, das System "kaputt" zu machen, um zu sehen, wie es darauf reagiert. 

Auch ist es wichtig zu überprüfen, ob die Implementierung der neuen Software bestehende Software an anderen Stellen beeinträchtigt oder Fehler hervorruft. Diese Regressionstests werden oft automatisiert durchgeführt, dennoch kennt der Tester oft das komplette System bei einer größeren Modullandschaft besser als der Entwickler, der sich oft auf einen bestimmten Bereich spezialisiert hat. Hier könnte man als grundlegendes Beispiel die Trennung zwischen Frontend und Backend nennen.

Eingeständnis eigener Fehler

"It wasn´t me!"

Es kann schwierig sein, eigene Fehler einzugestehen. Entwickler könnten dazu neigen, Fehler zu vertuschen oder zu rationalisieren, anstatt konstruktives Feedback anzunehmen und aus Fehlern zu lernen. 

Bugs werden möglicherweise schnell übersehen, um sich selbst nicht in ein schlechtes Licht zu rücken. Die Psychologie sollte in diesem Bereich nicht unterschätzt werden, denn wir sind alle Menschen und solches Verhalten ist menschlich.

Motivation zum Testen

"Eat the frog!"

Entwickler sind oft motiviert, neue Funktionen zu entwickeln und komplexe Probleme zu lösen. Das Testen kann als lästige Aufgabe erscheinen, die von der eigentlichen Entwicklung ablenkt.

 Wie würdet ihr eine Aufgabe erledigen, die euch nicht zusagt und nur lästig erscheint? Die Aufgabe würde nicht mit der Motivation durchgeführt werden, die ein Tester an den Tag legen würde, da es der Hauptteil seines Berufs ist, Bugs zu finden. Der Entwickler würde sicherlich nicht die Testtiefe erreichen wie der Tester.

 Natürlich gibt es hier Ausnahmen, die die Regel bestätigen.

Positives Testen

"Sometime the negative parts are also important, but only in testing!”

Entwickler testen oft darauf, dass ihre Software funktioniert, anstatt darauf zu testen, dass sie nicht funktioniert. 

Eine dedizierte QA hingegen konzentriert sich darauf, potenzielle Probleme und Schwachstellen aufzudecken. Wie bereits im Abschnitt "Erfolgsfall" beschrieben, erinnere ich mich hier immer wieder an den "Nerd-QA-Witz": 

"Geht ein QAler in eine Bar, bestellt 1 Bier, bestellt 2 Bier, bestellt 99 Bier, bestellt 0 Bier, bestellt -1 Bier, bestellt ein Bier, bestellt einen Leguan." Die Grenzwerte sollten beim Testing nicht vernachlässigt werden. Hier hilft einem die sogenannte Grenzfallanalyse.

Jeder kann testen

"Sure, I can do it! Easy peasy! What should I do in detail?"

Die schlimmste Aussage von einem Projektleiter, die ich gehört habe, war: 

"Wir haben Probleme Tester zu bekommen, warum geht ihr nicht mal an die Bushaltestelle und fragt die Leute dort, jeder kann doch Testen!" 

Das Testen erfordert spezifische Fähigkeiten und Kenntnisse. Während jeder Entwickler grundlegende Tests durchführen kann, ist eine professionelle QA in der Lage, umfassendere und effektivere Tests durchzuführen. Auch hier ist wieder die unterschiedliche Motivation und das über den sogenannten Tellerrand Denken oder "anders" Denken entscheidend. 

Ein Tester denkt anders als ein Entwickler.

Jeder kann auch ein Haus bauen, mit genug Zeit und Geld. Die Frage ist, wie gut ist die Qualität der Arbeit. Wie lange kann ich in dem Haus wohnen? Und: hätte ich das Haus schneller und stabiler bauen können mit einem Profi an meiner Seite oder einer Fachfirma?

Wirtschaftlichkeit

"Time is money, we have neither of them."

Entwickler haben oft ein Informatikstudium von 3-6 Jahren absolviert, während das Testen ein beliebter Quereinsteigerberuf ist. 

Es ist also nicht ungewöhnlich, dass ein Tester weniger verdient als ein Entwickler. 

Warum also einen teuren Entwickler die Arbeit einer "billigeren" Testkraft machen lassen, wenn das Ergebnis augenscheinlich dadurch noch besser wird? Eigentlich eine eindeutige Win-Win-Situation. Außerdem kann sich der Entwickler auf die Weiterentwicklung der Software oder die Implementierung weiterer Features konzentrieren.

DevOps und QA

"Cobbler should stick to his last” ( german phrase )

Der grobe Ansatz der DEVOps-Methodologie ist: Jeder soll alles können, zumindest ein bisschen. Ich sehe hier viele große Schnittmengen zwischen Entwicklern und Operations (Admins), jedoch zwischen QA und DEVs sehe ich eine klarere Trennung der Fachabteilung und Aufgaben. 

Ein agiles Team sollte nicht nur aus Entwicklern bestehen, sondern mindestens Produktmanager/Product Owner und QA als Teil des Teams haben. Nicht zu vergessen ist natürlich hier auch der SCRUM-Master. 

Die oben genannten Punkte sprechen eindeutig für eine thematische Trennung auch in agilen Teams. Eine komplette Übernahme der QA-Verantwortung und Aufgaben von den Entwicklern halte ich nicht für sinnvoll. Die Spezialisierung in dem Fachbereich ist einfach zu groß, nicht ohne Grund gibt es eine eigene Berufssparte für den Testing-Bereich.

Was sollte also ein Entwickler testen?

Entwickler sollten natürlich auch die Qualitätsfahne hochhalten und darauf achten, dass ihr Code so gut wie möglich getestet ist. Lokale Tests sowie Unit-Tests und Code-Reviews gehören hier in den Qualitätssicherungsprozess. 

Der Entwickler wird keineswegs "entlastet", nicht auf die Qualität des Produkts oder der Software zu achten. Hier ist eine wirtschaftliche Aufteilung der Aufgaben und Verantwortungen zwischen der QA und der Entwickler das A und O. Das obligatorische "Software einfach über den Zaun werfen" und die QA machen lassen, gilt schon lange nicht mehr. 

Schlussworte

Am Ende steht der Dienstleister mit seinem Namen in der Verantwortung, Qualität zu liefern, und nicht einzelne Abteilungen oder Mitarbeiter.

Eine dedizierte QA bietet eine Vielzahl von Vorteilen, darunter eine objektive Bewertung der Software, die Identifizierung von Problemen aus Benutzersicht und die Gewährleistung einer konsistenten Qualität.

Während Entwickler eine wichtige Rolle im Testprozess spielen, sollten sie nicht die alleinige Verantwortung für die Qualitätssicherung tragen. Eine professionelle QA kann dazu beitragen, die Qualität und Zuverlässigkeit der Software zu verbessern und das Vertrauen der Benutzer zu stärken.

Den einzig gegeben Vorteil, sollte ein Entwickler die Softwaretests übernehmen ist, das man keine QA einstellen, suchen oder ausbilden muss. Hier kann ich euch jedoch unterstützen und eure Qualitätssicherung auf das nächste Level heben und euch helfen wirtschaftlicher und effektiver in euren Agilen Teams zu arbeiten!

 Ich freue mich auf eure Kontakte, euer Feedback oder eure Ideen und Fragen.

Autor: Julian Farizi / 05/2024 / Should developers take over testing?