In den letzten Jahren meiner Tätigkeit als Scrum Master hatte ich das Glück, eine Vielzahl unterschiedlicher Projekte in diversen Organisationen mit variierendem Grad an Business Agility zu begleiten. Durch meine Arbeit in einer Beratung, die für ihre hohe Softwarequalität bekannt ist, habe ich ein besonderes Interesse daran entwickelt, wie Qualität in der Softwareentwicklung verankert wird – und wie stark sich dies nicht nur von Unternehmen zu Unternehmen, sondern sogar von Team zu Team unterscheidet. Aus diesen Beobachtungen heraus entstand mein Kernverständnis des Agilen Testers.
Natürlich wird dies in vielen Fällen stark durch die jeweilige Unternehmenskultur oder lokale Teamkultur beeinflusst. Dennoch bestehen oftmals erhebliche Unterschiede zwischen Teams, die eigentlich unter demselben kulturellen Dach arbeiten. Das hat mich zu der Frage gebracht: Warum ist das so?
Ein wesentlicher Grund dafür liegt meiner Ansicht nach in der Rolle des Agilen Testers und darin, wie sich diese Rolle zwangsläufig weiterentwickelt. Organisationen beginnen zunehmend, den wahren Wert leistungsstarker Agile Teams zu erkennen – und damit wächst auch die Bedeutung einer modernen, flexiblen Testrolle, die Qualität ganzheitlich versteht.
In diesem Beitrag beleuchte ich die traditionelle Rolle eines Softwaretesters, die typischen technischen und persönlichen Fähigkeiten, die er mitbringt, und zeige auf, wie sich diese mit den Anforderungen an den Agilen Tester der neuen Generation vergleichen lassen.
Der traditionelle Softwaretester
Obwohl ich tatsächlich ein zertifizierter Softwaretester bin, würde ich mich selbst ganz sicher nicht einstellen!
In meinem früheren Berufsleben als Business Analyst kam ich von Zeit zu Zeit mit Softwaretests in Berührung. Dabei stellte ich schnell fest, dass mir weder das tiefgehende technische Know-how noch die ausgeprägte Liebe zum Detail oder die notwendige Geduld fehlten, um ein wirklich herausragender Softwaretester zu werden. Deshalb war ich froh, diese Aufgabe den echten Experten für Softwarequalität zu überlassen.
Ein Satz, der mir seit meinen ersten Tagen im Training bei Expleo besonders im Gedächtnis geblieben ist, lautete:
„Ein guter Tester findet den schwer zu entdeckenden Fehler – aber ein großartiger Tester sorgt dafür, dass er auch behoben wird.“
Für mich bringt dies genau auf den Punkt, worum es bei einem typischen Quality Analyst (QA) geht. Ihre Aufgabe besteht darin, einen Plan zu erstellen, mit dem überprüft werden kann, ob sich die Software so verhält, wie es von den Produktverantwortlichen in den Anforderungen beschrieben wurde. Sie werden oft als die alleinigen Gatekeeper für Qualität gesehen.
Das bedeutet wiederum, dass im Falle eines Bugs, der unbemerkt bis in die Produktion gelangt, ihre Verantwortung auf dem Spiel steht. Dieses Rollenverständnis schafft eine Denkweise, nach der Quality Analysts alles bis ins Detail testen müssen, um zu verhindern, dass die „Leute in den schicken Büros“ mit einem Karton an ihrem Schreibtisch stehen, wenn etwas schiefgeht.
QAs werden aktiv dafür belohnt, Fehler zu finden, und viele verspüren ein starkes Gefühl von Erfolg und Bestätigung, wenn sie ihren 47. Bug des Tages entdeckt haben.
Es ist nicht unbedingt etwas Schlechtes, dass die Quality Gatekeeper sicherstellen wollen, jedes einzelne Problem zu entdecken, sobald ein neuer Code Drop in ihrer Testumgebung ankommt. Betrachtet man jedoch die zugrunde liegenden Motivationen, dann konzentriert sich der QA in erster Linie auf seine eigene Aufgabe: Bugs zu finden und deren Behebung voranzutreiben. Wenn ein Entwickler viele Fehler in seinen Code einbaut, verschafft das dem QA lediglich noch mehr Gelegenheiten, einen neuen Bug in Jira zu melden – etwas, das er anschließend stolz seinen QA-Kollegen präsentieren kann.
Es gibt zahlreiche Studien, die die Kosten für das Finden und Beheben von Fehlern in den unterschiedlichen Phasen des Produktentwicklungszyklus untersuchen. Tatsächlich hat Expleo kürzlich eine eigene Analyse veröffentlicht – 9 Wege, Business Agility durch Quality Assurance in den 2020er Jahren voranzutreiben.
Daraus wird schnell klar: Bugs so früh wie möglich zu finden und zu beheben – also Qualität nach links zu verschieben (Shift Left, dieser beliebte, aber oft missverstandene Begriff) – ist eindeutig ein Vorteil. Die entscheidende Frage lautet also: Wie können wir dies praktisch umsetzen und wie muss sich die Rolle des Testers weiterentwickeln, um dies zu ermöglichen?
Der Agile Tester
Eine der größten Veränderungen für einen QA – oder allgemein für jedes Mitglied eines Agile Teams – besteht darin, dass sie aufhören, nur für sich selbst zu arbeiten, und beginnen, für ihr Team zu arbeiten. Jedes Teammitglied sollte in einem angemessenen Maß verstehen können, welche Auswirkungen seine Handlungen auf die anderen Teammitglieder haben.
Expleo bietet eine Reihe von Trainings im Bereich Agile Testing an.
David Dwyer ist Principal Consultant bei Expleo. Er arbeitet überwiegend im Bereich Agile Enablement und unterstützt Organisationen dabei, ihre Business Agility zu verbessern – von der Team-Ebene bis hin zum C-Suite-Management. David verfügt außerdem über einen Hintergrund in der Business Analysis und ist daher besonders darauf fokussiert, Arbeitsweisen und Value Streams auf allen Ebenen einer Organisation zu optimieren.
Er ist qualifiziert, das ICAgile Fundamentals Training durchzuführen, und hat selbst eine Vielzahl an Weiterbildungen absolviert – von ICAgile Team Facilitator und ICAgile Product Owner bis hin zum BCS Diploma in Business Analysis, um nur einige zu nennen. David ist überzeugt vom Prinzip des Learning by Doing und bringt in seine Trainings eine ausgewogene Kombination aus fundiertem Fachwissen und praktischer Erfahrung ein.
