Erfahrungen als Embedded Tester im Scrum Team

Das Projekt, das vorgestellt wurde, ist ein „Grüne-Wiese-Projekt“. In drei Jahren muss eine komplette Systemlandschaft aufgebaut werden. Und genau hier gehen die Schwierigkeiten schon los, denn noch während die Systemlandschaft entwickelt wird, sollen Regressionstests für die Qualitätssicherung aufgesetzt werden. Tosca jedoch ist eigentlich darauf ausgelegt, Automatisierungen in einer bestehenden Systemlandschaft zu implementieren. Eine Vorarbeit in den Bereichen Requirements (Risk Based Approach) und  TCD (Methodik) ist aber sicher schon - anhand eines guten Prototypen - bis zu einem gewissen Punkt möglich. Aus der Erfahrung heraus zeigt sich jedoch, dass ab einer gewissen Grösse des Scrum Teams ein einzelner Embedded Tester nicht ausreicht, bzw. der Aufbau der Regression (einschliesslich ausgebautem TCD) nur durch ein nachgelagertes Regressionsteam zu meistern ist.

Was sich während des Vortrags bisweilen unterhaltsam anhörte, sind in der Arbeits-wirklichkeit echte Herausforderungen. Zum Beispiel, dass am Anfang eines Vorhabens oft die finalen Business Rules noch gar nicht vorhanden sind da diese erst iterativ definiert und implementiert werden - was dazu führt, dass man als fachlich ausgerichteter Embedded Tester vor der Frage steht, was denn überhaupt schon testbar ist (Unit Test/Code Reviews werden ja durch die Entwickler selbst abgedeckt).

Im Sinne von DevOps ist es sehr erfreulich - und von allen Parteien begrüsst - regelmässig Refinement Meetings und Reviews abzuhalten zu denen auch die End-Usern geladen sind. Die Herausforderung, die dies jedoch mit sich bringen kann ist, dass Änderungen mal eben ad-hoc implementiert oder entschieden werden - ohne jemals «offiziell» in einer JIRA Story oder einer anderen entsprechenden Dokumentation aufgenommen zu werden. Ein nachhaltiger Test mit entsprechendem Testnachweis ist dadurch schwierig. Abgesehen davon, dass die Beschreibung und Akzeptanzkriterien in der Entwicklerstory nun nicht mehr der tatsächlichen Implementation entsprechen, werden Rückschlüsse erschwert und Entscheidungen sind nicht mehr nachvollziehbar. Und natürlich auch der „Klassiker“ aus der agilen Entwicklung: Der Embedded Tester testet gerade eine Story, während der Entwickler aber schon wieder eine andere, neuere Variante implementiert, weil sich die Anforderungen aus dem Business geändert haben. Testevidenzen verlieren dadurch sehr schnell an Aktualität und werden obsolet bevor sie noch reported werden können. Auch dieses fast unlösbare Problem wurde in den Raum gestellt.

Als Teil des Development Teams der Entwicklungsfirma ist man auf das Testen in der DEV-Umgebung angewiesen. Ein Testen in der Testumgebung des Endkunden gestaltete sich gerade anfangs schwierig, da nicht regelmässig in diese deployed werden konnte. Mit dem Deployment in der Entwicklungsumgebung wurde zwangsweise auch die temporär integrierte Datenbank jedes Mal zurücksetzt.

Fakt ist: Der Embedded Test Manager kann immer nur das testen, was die Entwickler tatsächlich umzusetzen geschafft haben, mit anderen Worten: die Features, die es in den nächsten Release geschafft haben. Wenn die Entwickler die Stories, die sie sich vorgenommen hatten, nicht umzusetzen schaffen, dann sind sie im nächsten Release auch nicht vorhanden und können nicht getestet werden. Oft werden selbst die Entwickler erst gegen Ende des Sprints fertig, was dem Tester oft nur mehr wenig Zeit lässt, um alles noch im aktuellen Sprint zu testen, bevor dieser geschlossen wird. Bugs werden somit oft erst im Folgesprint zum ersten Mal begutachtet.

Schwierig wird es auch, wenn halbfertige Features geliefert werden. Der Embedded Tester machte deutlich, wie wichtig es ist, dass Features erst gelöst sein sollten, bevor sie in den Release gehen. Je mehr offene Bugs es gebe, desto grösser sei der Wartungs- und Nachverfolgungsaufwand. Der Tester appellierte an die Entwickler, von Anfang an möglichst sauber zu arbeiten, um Bugs und den damit verbundenen „Rattenschwanz an Evidenzen“ möglichst klein zu halten. Es sei sowieso schon unübersichtlich und komplex genug, wenn aufgrund der agilen Entwicklung der Button, den man testen sollte, plötzlich woanders stehe, was anderes mache oder anders heisse. Bezogen auf eine Automation zeigt, wird noch deutlicher, dass diese erst sinnvoll ist wenn der PO das neue Feature abgenommen hat und sich dieses durch neue Stories nicht mehr kurzfristig ändert. Bis also nicht eine gewissen Stabilität besteht, ist jede Art des automatisierten Fachtests nur «Waste».

Ein so wichtiger Vorteil der Scrum-Methode, nämlich dass während des Projektfortgangs praktisch jederzeit Änderungen und Verbesserungen möglich sind, bringt im Alltag eben auch gewisse Nachteile mit sich. Einerseits für Tester, deren Anspruch es ist, eine neue Funktionalität bereits geprüft in das Review mit PO und Stakeholdern zu schicken. Andererseits auch für die Entwickler, die sich in Review und Refinement stätig mit neuen Wünschen konfrontiert sehen. Hier sind die Werte Collaboration und Disziplin besonders gefragt.

Der Einblick, der den Mitgliedern der Interest Group Tosca gewährt wurde, war offen, ungeschönt und spiegelte die echten Erfahrungen des Embedded Testers in einem insgesamt 15-köpfigen Scrum-Team wider. An seinen Appell „Testing should be part of the story“ werden die Teilnehmerinnen und Teilnehmer bestimmt noch lange denken, denn damit sprach er ihnen aus der Seele.