Ich Entwickler, Du Tester

“The ratio of We’s to I’s is the best indicator of the development of a team.” (Lewis B. Ergen)

Laut Scrum Guide (siehe http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf) sind alle Mitglieder eines Scrum Teams Developer:

  • Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
  • ...
  • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

Allerdings treffen wir in der Realität immer wieder auf Teams, die sich in Entwickler und Tester unterteilen. Obwohl es natürlich valide ist, Leute mit unterschiedlichen Fähigkeiten in einem Scrum Team zu haben, führt dies manchmal zu zwei Subteams innerhalb von einem Team: die “wichtigeren” Entwickler, die die “richtige” Arbeit machen, und die “weniger wichtigen” Tester, die einfach nur den Entwicklern nachtrotten. Entwickler betrachten Testaufgaben oft als minderwertige Arbeit, und Tester wiederum tendieren dazu, diese Sichtweise zu unterstützen, indem sie sich selbst als nicht so wertvoll sehen, weil sie nicht das “magische” Wissen eines Entwicklers haben.

Das mag in den alten Zeiten des Wasserfalls funktioniert haben, wo es üblich war, den Testern gegen Ende eines Projektes ein fertiges Stück Software zusammen mit einem Wust an Requirements über den Zaun zu werfen. Die Aufgabe des Testers war es dann, herauszufinden, wie die Gedanken eines genialen Entwickler Hirns und diese Requirements zusammenhingen. (Und wie wir alle wissen, hat das damals auch nicht so wirklich funktioniert.)

Aber heute, in den neuen und strahlenden agilen Zeiten steht nun die Teamarbeit im Vordergrund und es geht um Teams, die gemeinsam Anforderungen in funktionierende Software überführen. So die Theorie.

Aber manchmal bin ich mir da nicht so sicher…

Planning II

Erst vor kurzem habe ich folgendes gehört: “Es macht keinen Sinn, dass die Tester auch am Planning II Meeting teilnehmen. Wie können sie wertvollen Input für die Implementierung liefern, wenn sie nicht die technische Expertise haben?”

Denken wir mal kurz über diese Aussage nach. Welche Fähigkeiten und Kenntnisse werden heutzutage von einem Test Engineer erwartet? Natürlich sollte er oder sie technik-affin sein, mittels SQL Statements Datenbankabfragen machen können und zumindest eine Script-Sprache beherrschen, um Testaufgaben zu automatisieren. Und außerdem ist er oder sie ein Experte für die Erstellung von Test Cases und kennt die vielen unterschiedlichen Testmethoden. Ein Entwickler hingegen weiß um die Tricks und Feinheiten der Java Bibliotheken und sollte außerdem auch schon mal etwas von Test Frameworks und Unit Tests gehört haben.

Aus der Kombination beider Rollen und deren Fähigkeiten ergibt sich das perfekte Paar. Sie ergänzen einander durch die Betrachtung unterschiedlicher Aspekte in der Software Entwicklung: Wie implementiere ich dieses Feature? Wie teste ich es? Wenn man schon vor der Implementierung über automatisierte Tests nachdenkt, hat das unter Umständen Einfluss auf die Architektur und das Design des Codes. Das Ergebnis ist eine Lösung, die leichter zu warten ist, und das Team wird bei der Aufrechterhaltung von hoher Qualität unterstützt, weil Testautomatisierung weder ignoriert noch auf einen späteren Zeitpunkt verschoben wird. Außerdem sollte sich das Team im Planning II Meeting nicht nur über die technische Umsetzung einer Story einig werden, sondern auch beschließen, wie eine Story zu testen ist und welche Tests benötigt werden (z.B. Unit Tests und/oder Integration Tests), um alle Akzeptanzkriterien der Story zu verifizieren und die Qualität der Umsetzung sicherzustellen.

Schätzen

Es ist das wöchentliche Refinement Meeting, der Product Owner erklärt die Story für die Integration eines neuen Kartenlesers in das bestehende Produkt. Die Entwickler sind bereits tief in der technischen Diskussion und die beiden Test Engineers hören respektvoll zu und warten ab, bis alle Fragen zwischen den Devs geklärt sind. Als es darum geht, die Poker Karten mit den Schätzungen zu zeigen, sind die Tester etwas zögerlich - ihre Schätzungen stellen sich als doppelt so hoch wie die der Entwickler heraus. Die Entwickler schauen ungläubig und die Tester sind kurz davor, ihre Schätzungen zurück zu nehmen und den niedrigen Zahlen der Entwickler zuzustimmen.

Doch nun springt der Scrum Master ein und bittet einen der Tester, seine höhere Schätzung zu erklären. Es stellt sich heraus, dass der aktuell definierte Workflow das Potenzial für missbräuchliche Verwendungen des Kartenlesers hat - und diese Möglichkeiten müssten alle getestet werden. Daraufhin folgt eine angeregte Diskussion, in die das gesamte Team involviert ist. Es wird überlegt, wie der Workflow zu ändern wäre, um nicht erlaubte Verwendungen zu verhindern. Nach 15 Minuten ist die Story komplett umgeschrieben und die neue Schätzung ist nun um einiges niedriger als die erste. Außerdem ist die neue Lösung leichter umzusetzen und zu warten.

War der Input der Tester nun wertvoller als die Expertise der Entwickler? Natürlich nicht. Der Nutzen entsteht aus der Kombination unterschiedlicher Sichtweisen und Erfahrungen aller Teammitglieder und daraus, dass jede Meinung gehört wird. Tester haben oft ein Verständnis für beide Welten, sowohl für die technische Domäne als auch für die Kundensicht, während Entwickler sich oft auf technische Machbarkeit und Wartungsfreundlichkeit konzentrieren.

Während des Sprints

Bei manchen Teams kann man während des Sprints einen Mini-Wasserfall beobachten: zu Sprint-Beginn fangen die Entwickler mit dem Codieren an, während die Tester noch die Tests vom letzten Sprint abschließen und darauf warten, bis die erste User Story fertig und zu testen ist. Und wenige Tage vor Ende des Sprints sind die Tester im Stress und die Entwickler beklagen sich, dass ihnen die Arbeit ausgeht.

Wenn das ganze Team dafür verantwortlich ist, ein funktionierendes Produktinkrement am Ende des Sprints zu liefern, was spricht eigentlich dagegen, die Tester zu unterstützen und noch ein paar der fehlenden Tests auszuführen? Oder, noch besser, technischen Support zu geben, damit die automatisierten Integration Tests endlich up and running sind, um das Leben jedes Einzelnen einfacher zu machen?

“Ich bin ein Entwickler und kein Tester.” Ich glaube, dass dieser Ausrede oft die versteckte Befürchtung zugrunde liegt, dass ich als Entwickler dann dazu verdammt werde, nur noch “niedrige” Testarbeiten zu erledigen. Hier ist es wichtig, dem Team zu vermitteln, dass Testing ein zentraler Bestandteil von agiler Softwareentwicklung ist und dass “gutes” Testen sehr wohl Raffinesse und Expertise erfordert, damit es effizient ist und Nutzen bringt. Daher sollte jedes agile Team Wert darauf legen, einen erfahrenen Tester in den eigenen Reihen zu haben. Das Ziel ist es dann, von dieser Person zu lernen, so dass schließlich jeder im Team in der Lage ist, Testaufgaben, wenn nötig, zu übernehmen.

Jeder ist involviert

Jeder, der daran beteiligt ist, Software zu liefern, ist ein Developer. Das inkludiert auch Mitglieder des Teams, die primär Testaufgaben erledigen. In einem wirklich cross-funktionalen Team sollte die Trennung zwischen Entwicklern und Testern sowieso mit der Zeit immer kleiner werden, weil das Team voneinander lernt, Wissen teilt und Aufgaben tauscht. Das gemeinsame Ziel ist die Verwandlung von Anforderungen in funktionierende Software - als ein Team von Developern.

17 Mär

Team Objectbay Skitage

Von Camilla Franek

Strahlend blauer Himmel, verschneite Bergspitzen und perfekt präparierte Pisten. Die besten Bedingungen, um in unsere Team Objectbay Skitage zu starten.

16 Feb

Und wo bleibt die Qualität? - Teil 2

Von Susanne Albinger

Es ist leicht, über Qualitätsbewusstsein und kollektive Verantwortung des Teams zu reden. Aber oft ist es eine Summe von kleinen Dingen und Praktiken, die ein Team in die Lage versetzen, konstant hohe Qualität zu liefern.


Neueste Artikel

  • Der Klebstoff, der alles zusammenhält

    24.04. / Susanne Albinger

    Man setze sechs Leute in einen Raum, versorge sie mit ausreichend Post-its, einem Taskboard und einem gemeinsamen Ziel und - voilá - fertig ist das Scrum Team! Hoch performant, kreativ und innovativ, und liefert alle zwei Wochen ein potentiell auslieferbares Produkt Inkrement. Klingt einfach. Aber…

  • Team Objectbay Skitage

    17.03. / Camilla Franek

    Strahlend blauer Himmel, verschneite Bergspitzen und perfekt präparierte Pisten. Die besten Bedingungen, um in unsere Team Objectbay Skitage zu starten.

  • Ich Entwickler, Du Tester

    15.03. / Susanne Albinger

    Laut Scrum Guide sind alle Mitglieder eines Scrum Teams Developer. Allerdings treffen wir in der Realität immer wieder auf Teams, die sich in Entwickler und Tester unterteilen. Sollte es in der Agilen Welt nicht um Teamarbeit gehen? Ein Team transformiert gemeinsam Requirements in funktionierende Software. Aber ist das wirklich so?

  • Und wo bleibt die Qualität? - Teil 2

    16.02. / Susanne Albinger

    Es ist leicht, über Qualitätsbewusstsein und kollektive Verantwortung des Teams zu reden. Aber oft ist es eine Summe von kleinen Dingen und Praktiken, die ein Team in die Lage versetzen, konstant hohe Qualität zu liefern.