Warum wir Deutschen im agilen Testen versagen

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.

  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks

8 Gedanken zu „Warum wir Deutschen im agilen Testen versagen“

  1. Hallo Markus,

    auf den Punkt gebracht! Genau die von dir angesprochenen Probleme habe ich gerade heute so erlebt. Nach meinem heutigem Tag als Troubleshooter in einem sehr softwarelastigen Automotiv-Entwicklungsprojekt kann ich deinen Beitrag so ausdrucken und allen Entscheidern unter die Nase halten.

    Der Software-Qualitäter stand heute bei mir und zeigte mir die Ergebnisse des Softwaretests. Er sollte für ein Software-Release das Releasedokument unterschreiben in dem aufgeführt war, dass die Testdurchführung zu 24 i.O. und 59 n.i.O. Testscenarien geführt haben. Und dazu war er, zu Recht, nicht gewillt.

    In den Gesprächen mit diversen Projektmanagern kam dann der Vorschlag auf den Tisch, die Werte in dem Releasedokument einfach wegzulassen, um den Kunden nicht zu beunruhigen. Was auch nicht die Lösung sein kann.

    Mein Eindruck ist, lange Jahre haben die Testabteilungen versucht an den Softwareentwicklern dran zu bleiben. Nun sind sie in der Lage mit intelligenten, statistisch verfeinerten und oft modelbasierten Testszenarien den Entwicklern das Wasser zu reichen. Die Ergebnisse sind natürlich ein riesen Haufen von neuen Auffälligkeiten. Die lassen sich zwar in die Bereiche Requirements, Testthemen und Softwarefehler aufteilen, aber führen doch insgesamt zu mehr gefunden Bugs.

    Und nun kommt natürlich die Frage auf, wie gehen wir in einem Projekt damit strategisch um? Mauern hochziehen, unter dem Teppich kehren oder einfach wieder zurückfahren kann nicht die Lösung sein.

    Ich denke die Lösung kann nur darin liegen zu verstehen, das die Rolle des Software-Testers, wie auch des Software-Qualitäters, darin liegen, dem Softwareentwicklern aufzuzeigen, wo noch Schwächen im Produkt liegen. Und den Software-Projektmanagern klar zu machen, dass sie zwischen dem Testreport und der Auslieferung eines Release mit zwei Stunden nicht klar kommen.

    Die Frage ist nur, wie schaffen wir es, mehr Verständnis auszubauen?

    Schönen Gruß aus Köln,

    Maik

    http://www.zukunftsarchitekten-podcast.de

  2. Hallo Markus,

    interessanter Eintrag.

    Bei uns in der Firma geht es gerade in die richtige Richtung, um mal ein positiv Beispiel zu bringen.
    Wir hatten vorher auch einen Raum in dem alle Tester saßen, also getrennt von den Entwicklern. Das komplette fertige Produkt haben wir auch meist erst am Schluss der Iteration komplett getestet, dann aber teilweise schon mit Unterstützung durch die Entwicklung.
    Aktuell haben wir uns neu aufgestellt, jedes Agile Team hat nun seinen „eigenen“ Tester im Raum sitzen.
    Und ich muss sagen das fühlt sich gut an. So wurde ich z.B. gleich am zweiten Tag von einem Entwickler nach Testfällen für seine Unit-Tests gefragt, im Gegenzug dazu hat sich der Entwickler unsere automatischen Tests angesehen und hat wertvolle Tipps zum Refactoring geben können.
    In unseren Teams ist es somit ein Geben und Nehmen und die Entwickler bekommen nun noch besser mit wie wir Tester arbeiten.
    Bin gespannt wie es sich weiterentwickelt.

    Gruß,
    Sven

  3. Hi Markus,
    ich stimme mit großen Teilen des blogs überein, mag allerdings die Überschrift nicht. „Warum wir Deutschen im agilen Testen versagen“ ist eine weitreichende Aussage, die natürlich nicht auf alle Deutschen zutrifft und zum Anderen agiles Testen auch in anderen Ländern ein Problem darstellt. Sprich die künstliche Einschränkung auf Deutschland ist meiner Meinung nach nicht hilfreich.

    Wenn ein Projektleiter Testergebnisse nicht an den Kunden weiterleiten will, ist das kein Test-sondern Ethikproblem. Eventuell auch ein Skill-oder Wissensproblem. Angst spielt auf jeden Fall eine Rolle.
    Zum Entmündigen einer erwachsenen Person gehören immer zwei. Es gibt natürlich die Möglichkeit dagegen anzugehen oder, wie die Briten sagen, mit den Füßen zu wählen.
    Das eigentliche Problem ist kein Testproblem. Es ist Angst und Unwissenheit zumeist auf der Managementebene, die von Testern, also meistens von unten schwer (aber nicht unmöglich) anzugehen ist. Diese Ebene anzugehen ist meiner Meinung nach sehr sinvoll. Alternative test- Methoden / Herangehensweisen / Tools / gibt es genug. Die Herausforderung liegt nun darin, diese auch zu Erklären und den Sinn und Nutzen für Nicht-Tester zugänglich zu machen.

    1. Hallo Thomas,

      ich stimme Dir zu in weiten Teilen. Den Titel habe ich so gewählt um auszdrücken, dass ich mir bei Deutschland sicher bin, aber vom Rest der Welt zu wenig gesehen habe, um darüber eine fundierte Meinung wiedergeben zu können.

      Überzeugug des Managements ist eine längere Reaktion wert. Ich gucke mal, ob ich das in den kommenden Tagen hinbekomme.

  4. Hi Markus,

    guter Beitrag – genau diese Diskussion hatte ich gestern im Kollegenkreis. Insbesondere die Einbindung des Kunden in Statusberichte gleicht vielfach einem Sakrileg!

    1. Hallo Ralf,

      dabei ist doch auch tradtitionelles Testen auch durchaus darauf aus, eine enge Zusammenarbeit mit dem Kunden herzustellen. Wenn ich den Kunden in meine Statusberichte einbinden kann, dann schafft das zwar erstmal unangenehme Transparenz, aber dafür muss ich weitaus weniger Energie in das Verstecken und Verheimlichen dieser unangenehmen Nachrichten aufbringen – Energie, die ich dann noch viel besser für die Softwareentwicklung stecken kann.

      Natürlich würde ich die Kundeneinbeziehung nicht leichtfertig beginnen wollen. Letzten Endes muss ich ja auch erstmal so etwas wie eine Vertrauensbasis aufbauen. Deshalb sollten wir vielleicht eher die Frage stellen, was wir an Vorleistung bringen müssten, damit der Kunde uns respektvoll behandeln kann? Die Antwort darauf kann Berge versetzen.

  5. Moin Markus,
    auch ich trage mal ein positives Beispiel bei, denn die Produktionscode-Entwickler[1] mit denen ich arbeite, wollen Geschäftsprozesstests für sich nutzen, um eben zu sehen, wenn sie etwas ändern, das das vielleicht noch etwas genauer gemacht werden muss. Auch benutzen Anwenderinnen und Anwender die Software manchmal anders als gedacht (wer weiß das nicht), und eben diese, manchmal für uns umständlich erscheinenden Wege, sollte man auch nicht durch Umbauten verbauen.

    – Qualität muss man produzieren – und da die Tester nominell immer weniger stark in einem Projekt vertreten sind, sollte man auch mal erörtern, welche Qualität denn wie erzielt werden soll.

    Ich glaube aber nicht daran, dass es ein rein deutsches Problem ist, sondern wer die Qualität definiert. Akzeptiert man das was Regulatorien, Gesetzgebungen und Unternehmensvorschriften sagen, ist es deren Qualität. Geht man einen Schritt weiter und definiert darüber hinaus seine zu produzierende Qualität ist es etwas gemeinschaftliches, etwas wo man auch für einstehen möchte.

    Herzliche Grüße
    Jogi

    [1] Entwickler sind wir alle, die zu einem Projekt etwas beitragen, gemäß Agile Testing :-)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.