Seit einiger Zeit wächst in mir die Erkenntnis, dass irgendwas grundlegend schief läuft beim Testen in agilen Projekten in Deutschland. In meinen Augen gibt es einige fundamentale Mißverständnisse, wenn es um agile Softwareentwicklung im Speziellen, aber auch wenn es um Softwaretesten im Allgemeinen geht. Dieser Blogeintrag soll einen Startschuss dazu geben, diesen Zustand zu ändern – ohne Anspruch auf Vollständigkeit der Dysfunktionen rund um agiles Testen in Deutschland zu erheben. Und ja, es gibt auch einige Positivbeispiele, die ich auf meinen Reisen quer durch die Republik gesehen habe.

Testen im zweiten Quadranten

Seit einiger Zeit beschäftigt mich die Erkenntnis, dass es den meisten Testern schwierig fällt, wie sie ein Entwicklungsteam konstruktiv unterstützen können. In meinen Schulungen schlägt sich das bei der Testquadranten-Übung stets so nieder, dass bei einem Brainstorming von Aktivitäten der zweite Quadrant der agilen Testquadranten verhältnismäßig leer bleibt. Bei der Übung frage ich Tester danach, welche Aktivitäten und Testmethoden sie kennen, und lasse sie diese auf die vier Testquadranten nach einer kurzen Einführung mappen. Der Bereich um die technisch-orientierten Tests, die dem Team weiterhelfen, sowie die geschäfts-orientierten Tests, die das Produkt kritisieren, ist dabei sehr klar. Genauso der vierte Quadrant mit technisch-orientierten Tests, die das Produkt kritisieren. Der Bereich um geschäftlich-orientierte Tests, die dem Team helfen sollen, allerdings ist meistens sehr leer.

Ich führe das auf eine Fehleinschätzung aus der traditionellen Testlehre zurück. Diese Miskonzeption beruft sich darauf, dass Tester und Entwickler unabhängig von einander sein sollten. Schließlich kann ein Entwickler mit seinem Positivismus den kritisch-denkenden Tester dahingehend beeinflussen, dass er nicht so ausführlich testet oder aus Gefälligkeit den Entwicklern gegenüber nicht so gründlich ist. Natürlich besteht die Gefahr eines derartigen kognitiven Bias, doch wie hoch sind die Kosten, wenn ich Tester und Entwickler davon entmündige, selbst aus ihren Fehlern lernen zu können?

Ich habe Firmen gesehen, in denen es verboten war, dass Programmierer mit Testern sprechen. Dort flossen alle Informationen über das Bugtracking-Tool, jenseits von jeglicher menschlichen Nähe, mit all den negativen Konsequenzen wie einer Blaming-Kultur, Misstrauen und sog. Information Hiding. Mit Abstand betrachtet floss in diesen Unternehmen mehr Energie darin, fehlerfrei auszusehen, als dass gute Arbeit geleistet wurde. Oh, und natürlich müssen Biological Testing Units stets ausgelastet sein, damit sie die höchste Produktivität erreichen können.

Auf der anderen Seite habe ich Teams gesehen, die den Sprung von räumlich getrennten Testern hin zu vollständig co-located Teams gemacht haben. Auch wenn der Tester nur zwei Räume weiter saß, haben sich dramatische Verbesserungen ergeben, wenn der Tester beim Team sitzen konnte. Auf einmal war Pro-Aktivismus nicht nur beim Stand-Up offensichtlich. Der Tester konnte auch öfter Teammitglieder um Hilfe bitten, und langfristig entwickelte sich ein Vertrauensverhältnis zwischen Entwicklern und Testern.

Letzten Endes ist es eine dramatische Falle zu glauben, nur weil Tester und Entwickler nicht miteinander reden dürfen, seien Tester unabhängiger. Das gleiche Argument kann ich zum Beispiel auch anführen, wenn Tester andere Dokumentation über das Projekt bekommen, andere Statusberichte abliefern müssen und andere Kunden als Ansprechpartner haben. Dann wären sie doch vollends unabhängig von den Entwicklern. Tester zu entmündigen, indem man ihnen die Fähigkeit aus Fehlern zu lernen, abschreibt, ist in meinen Augen das Nummer eins Problem in der Softwareentwicklung. Dadurch entmündigt man nicht nur erwachsene Menschen, man bevormundet sie auch. Natürlich alles im Namen der Qualität. Doch was ist das eigentlich? Qualität?

Qualität ist Mehrwert für jemanden

„Qualität ist, was immer mir gefällt“ könnte ein passender Ausspruch sein. „Ich erkenne Qualität, wenn ich sie sehe“ ist ein vergleichbar schwammiges Statement. Jerry Weinberg hat in den 90er Jahren mit seinem Zitat „Quality is value to some person“ den Nagel auf den Kopf getroffen. Mehrwert für einen User kann weniger Wert für einen anderen bedeuten. Beispielsweise wollen wir cross-site scripting Attacken unterbinden, damit die zahlenden Kunden trotzdem noch unsere Applikation verwenden werden, aber Hacker ausgesperrt sind.

Bei der Softwareentwicklung geht es darum zu identifizieren, auf wen wir bei der Qualitätsbetrachtung achten sollen, und unterschiedliche Bedürfnisse gegeneinander abzuwägen. Tester liefern hier einen großen Mehrwert mit ihrer Fähigkeit, kritische Fragen richtig stellen zu können. Sie sind in der Lage Fehlerszenarien zu erdenken, bevor sie ein (unerwünschter) User des Systems haben kann. Doch dafür müssen sie früh eingebunden sein – idealerweise zeitgleich mit dem Rest des Entwicklungsteams, wenn nicht sogar noch früher.

Aber man kann doch erst nach der Fertigstellung testen!

Falsch. Ich kann bei der Anforderungsanalyse, im Spezifikations-Workshop, beim Coding und nach der Fertigstellung der Software testen. Dafür habe ich gelernt, die richtigen Fragen zur richtigen Zeit zu stellen. Manchmal lerne ich neu, dass ich gewisse Fragen etwas mehr zurückstellen muss, oder erstmal ein generelles Bild für das kommende Release entwickeln muss, bevor ich sie stelle. In jedem Fall kann ich nicht nur testen, wenn der Code fertig ist, und ich eine fertige Applikation habe. In jedem Fall kann ich immer etwas lernen, wenn ich mir selber einen Ruck gebe, und noch eher einsteige, als mein persönliches Wohlbefinden für richtig erachten würde.

Mein Hauptkritikpunkt liegt hier wieder in der Entmündigung von Testern durch vorgegebene Testskripte in Form von sog. strukturierter Testfallanalyse und Testplänen, die letzten Endes nur die Freiheit des erwachsenen Testers einschränken. Doch dadurch lässt sich ja die Anforderungsabdeckung haargenau nachvollziehen. Noch viel trauriger ist allerdings, dass wir kein anderes Mittel als die kreative Einschränkung durch Testskripte kennen. Natürlich ist die Alternative von Explorativem Testen, die in den meisten Firmen in Deutschland gelebt wird, noch viel schlimmer. Das liegt aber doch nicht daran, dass Exploratives Testen böse ist, sondern dass wir Tester stets entmündigen müssen, so dass sie nicht lernen und daran arbeiten, ihre Fähigkeiten zu verbessern und besser explorativ testen zu können. Auch hier habe ich bereits signifikante Verbesserungen erlebt dadurch, dass ich ein paar wenige Hinweise für besseres exploratives Testen wie session-basiertes Testmanagement, ein Low-tech Testing Dashboard oder auch einfach nur Testcharter für individuelle Testaktivitäten gegeben habe.

Tester können doch nicht programmieren

In meinen Augen einer der schlimmsten Sünden ist, dass wir Testern absprechen, neue Fähigkeiten lernen zu können, ja sogar lernen zu wollen. Programmierer konnten auch nicht immer programmieren, trotzdem haben sie es irgendwann gelernt. Noch viel schlimmer ist es, dass ich im vergangenen Jahr von einem Entwickler gehört habe, der an seinen Schreibtisch ging, seinen Arbeitsvertrag herausholte, und meinte: „Da steht nichts von Unittesten drin!“ Vergleichen Sie Ihre Reaktion einmal mit der folgenden Geschichte, die ich vor ein paar Woche hörte: Ein Tester geht an seinen Schreibtisch, holt seinen Arbeitsvertrag raus, und meint: „Da steht nichts von Programmieren drin!“ – Wieso ist Ihre Reaktion auf einmal gänzlich anders?

Tester können lernen zu programmieren. Man muss ihnen häufig nur die Angst davor nehmen. Das kann man zum Beispiel dadurch schaffen, dass man Pair Programming einsetzt, und ein Tester so sein Testwissen gezielt an einen Entwickler beim Unittesten weitergibt, und dabei ein paar neue Kenntnisse über das Programmieren vom Programmierer erlernt. Mein Vater sagte mir einmal, dass er kurz nach seiner Ausbildung gelernt hat, dass er im Leben nie auslernen wird. Mein Vater war Automechaniker, und nach der Ausbildung in den 70ern, musste er sich mit immer mehr technologisierten Maschinen auseinandersetzen. Seitdem weiss ich, dass mir das ähnlich gehen wird, und ich versuche kontinuierlich meine Grenzen zu erweitern. Dieses Mindset vermisse ich in den meisten Softwarefirmen.

Holistische Sicht

Alles in allem fehlt es uns in Deutschland an einer holistischen Sicht auf die Arbeit, die wir tun. Dadurch dass wir die Wände zwischen Programmierern und Entwicklern so künstlich aufrechterhalten, entmündigen wir nicht nur unsere Tester, nein, wir geben ihnen sogar Futter dafür, in ihrer jeweiligen Komfortzone zu einem Ten-to-Four-Worker zu mutieren, der das Ende seiner Karriereleiter verwirkt hat. Schade. Dabei haben wir so ein großes Potential, das wir nicht zu nutzen wissen. Denn letzten Endes kommt es als Team darauf an, dass wir ein funktionierendes System ausliefern können – und das in agilen Projekten in jeder Iteration. Wenn wir das nicht hinbekommen, können wir unsere Aufwände auch gleich sein lassen – denn sie sind nichts weiter als verschwendete Zeit, wenn wir es nicht hinbekommen, in zwei Wochen die Software nicht nur zu entwickeln, sondern auch durch gutes Testen ausreichend beleuchtet zu haben, dass wir sie ruhigen Gewissens ausliefern können.