31. Mai 2022
Können Tester und Entwickler Freunde werden?
Die Beziehung zwischen Softwaretestern und Softwareentwicklern ist nicht selten angespannt. Oft herrschen auf beiden Seiten Gefühle von Überheblichkeit und zähneknirschender Abhängigkeit.
Auf der einen Seite leiden Tester bisweilen unter der weit verbreiteten Vorstellung, das Testen von Software sei eine weniger schwierige oder anspruchsvolle Aufgabe als die Entwicklung von Software. Dieser Eindruck wird verstärkt von Unternehmen, die den "Aufstieg" vom QA-Ingenieur zum "richtigen" Softwareentwickler zu einem Schritt auf ihrer internen Karriereleiter machen.
Tester müssen außerdem häufig geradezu betteln um die Entwicklung "zusätzlicher" Funktionen wie Abwärtskompatibilität und Labels für die Barrierefreiheit, die von Entwicklern bisweilen als überflüssig und mühselig angesehen werden.
Die Entwickler wiederum hören oft nur dann von der Qualitätssicherung, wenn es ein vermeintliches Problem mit ihrer Arbeit gibt. Niemand hört gerne, dass er einen Fehler gemacht hat, und nicht jeder kann immer gut mit Kritik umgehen.
Dabei sind die Entwickler tatsächlich auf die Sorgfalt und das Wissen der QA-Abteilung angewiesen. Ich habe selbst erlebt, wie Entwickler "technisch korrekte" Software entwickeln, ohne den zugrunde liegenden Anwendungsfall wirklich verstanden zu haben. Die Folge sind merkwürdige Eigenheiten der Software, die ohne genaue Kenntnis der Geschäftsdomäne schwer zu erkennen sind.
Die Frage ist: Was können Softwareunternehmen tun, um diese Spannungen zu verringern?
Können wir das Bauen von Software so einfach machen, dass es jeder kann?
Eine Idee könnte sein, daran zu arbeiten, traditionelle Kenntnisse der Software-Entwicklung für die Erstellung neuer Anwendungen überflüssig zu machen.
Dies war das Ziel der "Low Code"-Bewegung. Die Idee, manchmal auch als "visuelle Programmierung" bezeichnet, bestand darin, "Metaprogramme" zu entwickeln, mit denen man neue Anwendungen für einen bestimmten Geschäftsbereich aus visuellen Blöcken, Vorlagen und kleinen Skripten zusammenstöpseln könnte.
Motivation dafür war ursprünglich der anhaltende Mangel an Softwareentwicklerinnen und -Entwicklern. Dieser Mangel führt dazu, dass Unternehmen nicht in der Lage sind, ihre Software schnell genug weiterzuentwickeln um mit der Nachfrage und dem Wettbewerb Schritt halten zu können.
Anstatt jede Software von Grund auf neu zu programmieren, könnten Softwaretester (oder auch Manager und Endanwender) ein "No-Code"- oder "Low-Code"-Tool verwenden, um aus vorhandenen Bausteinen eine neue Software für ihre Bedürfnisse zusammenzustellen. Dadurch würde sich die Aufgabe der Softwareentwickler auf die Programmierung des ursprünglichen Tools reduzieren.
Die so entstandene Software müsste natürlich immer noch gründlich getestet werden, um sicherzustellen, dass sie die ursprünglichen Spezifikationen erfüllt. Aber das Skillset der Softwaretester, die ja am besten wissen, was Software tun soll, eignet sich gut sowohl für die Erstellung als auch das Testen von "Low-Code"-Software.
Der Traum, die Entwicklung von Software so einfach wie die Bearbeitung einer Excel-Tabelle zu machen, ist jedoch weitgehend geplatzt.
Die meisten Softwareanforderungen sind im Detail zu komplex und spezifisch, um in ein modulares System zu passen. Im besten Fall ist es möglich, eine Software zu entwickeln, die die ursprünglichen Spezifikationen einigermaßen erfüllt, dabei aber voller Kompromisse, stark vereinfacht und umständlich zu bedienen ist. Software aus einem modularen System wird es immer nötig machen, dass sich Anwender an sie anpassen, anstatt ihren Anwendern zu dienen.
Einige dieser "Low-Code"-Ideen haben sich in modernen Website-Baukästen und einigen Tools zur Prozessautomatisierung gehalten und waren in diesen begrenzten Bereichen erfolgreich. Aber sie sind bei weitem kein Allheilmittel, das es Testern ermöglicht, ohne die Hilfe von Entwicklern auszukommen.
Können wir Testen so bequem machen, dass es jeder Entwickler selbst kann?
Wie wäre es also, wenn wir unser Tester-Entwickler-Problem in die andere Richtung lösen? Können wir das Testen von Software so bequem für Entwickler machen, dass sie sich selbst darum kümmern können?
Die meisten Softwareentwickler wissen heute, wie wichtig Tests sind. Viele nutzen Tests sogar als Kernbestandteil ihres Entwicklungsworkflows, wie bei der testgetriebenen Entwicklung (TDD).
Entwickler bevorzugen jedoch die Art von Tests, die sie mit ihren gewohnten Tools schreiben, ausführen und warten können. Entwickler schreiben Tests im Code: Unit-Tests, die sie schnell und ohne Umwege ausführen können.
Und Entwickler testen normalerweise nur den Code, an dem sie gerade arbeiten und für den sie verantwortlich sind. Selten passt es in den Arbeitsablauf eines Entwicklers, Integrationstests zwischen Systemen von verschiedenen Entwicklern oder Teams zu schreiben, ganz zu schweigen von Ende-zu-Ende-Tests.
Bei der testgetriebenen Entwicklung spielt auch das Verhalten auf anderer Hardware oder anderen Betriebssystemen oder auf älterer Hardware oder Software in der Regel keine Rolle. "Läuft bei mir" ist das Mantra für die Sorte Tests, die Entwickler zur Unterstützung ihrer Arbeit schreiben.
Wenn sie komplett selbst für das Testen verantwortlich sind, werden Entwickler auch dazu neigen, Code zu vermeiden, der mit ihren bevorzugten Testmethoden schwer zu testen ist. Das bedeutet vor allem, dass sie so wenig UI-Code wie möglich schreiben und Zustandsabhängigkeiten vermeiden, wo immer sie können.
Das Endergebnis ist eine Software, die einer Kommandozeilenschnittstelle gleicht: technisch korrekt, aber schwer zu bedienen und zu verstehen.
Können wir uns in der Mitte treffen?
Was ich gerade beschriebe habe, sind keine Lösungen, sondern eher Softwarequalität-Albtraumszenarien. Lieber sollten wir versuchen, die besten Eigenschaften beider Ansätze zu kombinieren.
Dazu brauchen wir zwei Dinge: Kommunikation und Respekt zwischen Testern und Entwicklern. Die Probleme zwischen Testern und Entwicklern sind nicht technischer, sondern organisatorischer Natur. Und deshalb brauchen sie eine organisatorische Lösung.
Unternehmen sollten ein positives Verhältnis zwischen Testern und Entwicklern fördern. QA- und Entwicklungsteams sollten ermutigt werden, zusammenzuarbeiten und ein paar Meilen in den Schuhen des anderen zu gehen. Entwickler müssen für die Tools und Arbeitsabläufe sensibilisiert werden, die die Qualitätssicherung für ihre Arbeit benötigt. Tester hingegen sollten zumindest ein flüchtiges Verständnis davon erlangen, wie Software entwickelt wird. Und die Unternehmen sollten so strukturiert sein, dass sie nicht Wettbewerb zwischen Teams fördern, sondern das Hinarbeiten auf ein gemeinsames Ziel.
Ich weiß, das ist viel leichter gesagt als getan. Aber die Kluft zwischen Testern und Entwicklern ist nicht so groß, wie es manchmal scheint. Wenn jeder die eigenen Fähigkeiten und Fokus einbringen kann, können wir gemeinsam großartige Software entwickeln.