Warum Entwicklern das Testen so schwer fällt – und wie man besser werden kann

Entwickeln und Testen – Zwei Logiken treffen aufeinander
Kommentare

Eine Studie aus dem Herbst letzten Jahres kam zu ernüchternden Ergebnissen, was die Testing-Qualitäten von Entwicklern angeht. Diese glauben zwar, ausreichend zu testen, aber mit der Realität hat ihre Selbsteinschätzung wenig zu tun. Das mag sicherlich mit dem generellen Unwillen gegenüber Testing zu tun haben, den die Studie ebenfalls festgestellt hat. Aber woran liegt es, dass Testing als eine lästige Pflicht angesehen wird? Sind Entwickler einfach zu faul und wählerisch?

So einfach wird es wohl kaum sein. Joel Montvelisky zeigt in seinem Artikel, dass weniger subjektive Faktoren eine Rolle spielen, sondern dass die Logiken von Testing und Entwicklung zu verschieden, ja geradezu gegensätzlich sind. Das macht es äußerst schwierig, zwischen beiden Logiken zu wechseln bzw. das Mindset des Testers auf das eigene Werk anzuwenden. Montvelisky hat einige Aspekte des Problems notiert, die hier zunächst wiedergegeben seien:

Emotionale Bindung

Jedes Arbeitsprodukt ist eine Veräußerung meiner selbst. Erzählt mir jemand, dass in vielen Stunden meiner Lebenszeit nichts Vorzeigbares entstanden ist, beziehe ich das immer auch auf mich, obwohl ich weiß, dass es nicht persönlich gemeint ist. Deswegen reagieren Programmierer gelegentlich allergisch auf Kritik, obwohl sie bei anderen schnell die Perspektive des Testers einnehmen.

Zumal beim Testing häufig auf Details gezielt wird, während bei der Entwicklung gewissermaßen ein Gesamtkunstwerk aufgebaut wird. Wie Mike Sparks treffend bemerkt, ist es äußerst frustrierend, wenn an einer vollständigen Software nur wegen eines kleinen Bugs gemäkelt wird. Aber Achtung: Es scheint nur so, denn auch die Tester sind natürlich an einem guten Endprodukt interessiert.

Kreation vs. Destruktion

Damit vergleichbar ist der Kontrast bei den Herangehensweisen an eine fertige Software. Während Entwickler komplexe Probleme nehmen und in Programmstruktur und Code übersetzen, um schließlich ein für die User möglichst leicht bedienbares Produkt vorzeigen zu können, gehen Tester genau andersherum vor. Sie nehmen eine simple Funktion und versuchen, sich die krudesten und komplexesten Szenarien auszudenken, mit denen die Funktion und das gesamte Programm ruiniert werden können.

Überhaupt ist mutwillige Destruktion ja Sinn und Zweck des Testings; es will herausfinden, an welchen Stellen Schwachstellen zu finden sind. Das passt natürlich nicht mit dem Anspruch der Entwickler zusammen, Architekten und Baumeister zu sein. Während sie sich darauf freuen, etwas Funktionierendes herzustellen, müssen die Tester prüfen, ob die Software nicht irgendwo einsturzgefährdet ist.

Go for PHP Developers

mit Terrence Ryan (google)

Everything you need to know about PHP 7.2

mit Sebastian Bergmann (thePHP.cc)

Dazu machen sie sich auf die Suche nach Unregelmäßigkeiten. Daran zeigen sich ein weiteres Mal die gegenteiligen Mindsets: Auf der einen Seite versuchen Entwickler Regeln, Muster und Schablonen aufzustellen, auf der anderen Seite versuchen die Tester herauszufinden, ob etwas in den Regeln nicht aufgeht und Probleme verursachen könnte.

Generell gilt: Entwickler bejahen, Tester verneinen – zwischen diesen Herangehensweisen hin- und herzuswitchen ist alles andere als einfach.

Der User: das unbekannte Wesen

Entwickler arbeiten häufig abgeschirmt von denjenigen, die ihre Produkte am Ende nutzen. Häufig werden sie angestellt, um Code zu schreiben, aber letztlich ohne zu wissen, wie die User mit dem fertigen Produkt umgehen werden. Im Gegensatz zu professionellen Testern fällt es ihnen daher schwer, mögliche Schwierigkeiten der User zu antizipieren. Programmierer liefern einen Rahmen für die User, aber Tester müssen im Namen der User versuchen, den Rahmen zu sprengen.

Wie werden Entwickler bessere Tester?

Dazu hat Montvelisky ebenfalls einige Hinweise notiert. Zunächst einmal gilt es, Vorbehalte abzubauen, damit das Testing nicht länger als Pflicht und Maßregelung angesehen wird, sondern als integraler Bestandteil des Entwicklungsprozesses. Auf diese Weise erscheint es nicht mehr als Angriff auf mein Produkt (und darüber auf mich).

Das ist zunächst eine Frage der Unternehmenskultur: Wenn das Testing im Unternehmen selbst nur als notwendiges Übel betrachtet wird, werden die Korrekturen der Tester eher als lästig oder gar peinlich, soll heißen als jobgefährdend, wahrgenommen. Stattdessen sollte eine Atmosphäre etabliert werden, in der man sich Grenzen und Schwächen eingestehen kann, das Testpersonal respektiert wird und Kritik als Möglichkeit der Verbesserung angesehen wird. Dann lassen sich auch die Ergebnisse aus den Testläufen besser annehmen.

Diese Dinge fallen allerdings in den Aufgabenbereich des Managements. Ansonsten bleibt der schwierigste Teil, sich als Entwickler in die Denkweise der Tester einzufinden. Dazu einige Anmerkungen:

  • Nicht den eigenen Code testen: Erstens sieht man bei den eigenen Arbeiten häufig den Wald vor lauter Bäumen nicht mehr und zweitens will man ihn unbewusst vielleicht gar nicht sehen. Besser, man widmet sich den Arbeiten anderer, dort ist man objektiver.
  • Erst denken, dann testen: Blind drauflos zu testen, dürfte wenig bringen. Zunächst mal muss man sich darüber klar sein, welche Szenarien es geben könnte und am wichtigsten: wie die User die Software brauchen und missbrauchen werden.
  • Systematisch vorgehen: Checklisten und sorgfältige Dokumentation des Testvorgangs verhindern unbeabsichtigte Leerstellen.
  • Auf die Profis hören: Übung macht den Meister, das gilt auch für die Fehlersuche. Tester machen ihren Job jeden Tag, logischerweise haben sie ein Auge für die Probleme von Software. Ihre Expertise hin und wieder mal anzufragen, schadet auf keinen Fall.
  • Think Outside the Box: Beim Coding geht man recht geradlinig vor. Es gibt Sachen, die gehen, und solche, die nicht gehen. Für den User spielt das keine Rolle, also muss man sich beim Testen außerhalb vorgegebener Bahnen bewegen. Es hilft deshalb, offen zu sein: verschiedene Interessen, unterschiedliche Lektüre oder originelle Spiele helfen dabei, mental nicht einzurosten.

Fazit

Für Entwickler ist das Testing häufig schwierig, weil sie sich auf eine veränderte Aufgabenstellung einlassen müssen. Doch am Testing führt nichts vorbei! Es ist darum hilfreich, sich die kontraintuitiven Denkstrukturen vor Augen zu führen und gelegentlich zu trainieren. Am besten natürlich durch learning by doing!

Aufmacherbild: Confrontation von Shutterstock / Urheberrecht: inspired_by_the_light

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -