Das Qualitätssichern und Testen von Entwicklungsergebnissen ist sicherlich ein streitbares Thema in der Agilen Softwareentwicklung. Es gibt viele verschiedene Ansätze die Softwaretester in den Entwicklungsprozess einzubeziehen. Je nachdem wie das Thema Qualitätssicherung im Unternehmen bereits gelebt wurde, findet das Sichern der Qualität an verschiedenen Punkten im Entwicklungsprozess statt. Manche Unternehmen präsentieren ein Inkrement der Qualitätssicherung erst nachdem es fast fertig ist, andere wiederum erstellen ein eigenständiges Test-Backlog und führen die Aktivitäten parallel zum dem eigentlichen Sprint Backlog.
Ich beobachte einige Vorteile wenn man den Softwaretester, in der Rolle ähnlich wie einen Entwickler betrachtet und direkt in ein Agiles Entwicklungsteam integriert. Im besten Fall sind Softwaretester auch Entwickler oder besitzen genug technisches Verständnis für die Architektur der Softwareproduktion. Die Softwaretester sollte bei den Scrum Meetings Backlog Grooming und Sprint Planning anwesend sein. Im Rahmen dieser Meetings werden die Details der Anforderungen besprochen und mögliche Umsetzungswege diskutiert. Hierbei bildet sich Domänenwissen zum Softwaerprodukt (oder Inkrement), welches sich im besten Falle unter allen Team Mitgliedern verteilt. Das Domänenwissen kann in der Qualitätssicherung verwendet werden kann, um zielgerichtet Testfälle zu spezifizieren oder um einfach besser zu verstehen was einzelne User Stories wirklich beinhalten. Der Softwaretester ist sicherlich ein guter Ansprechpartner um Informationen zur Umsetzung aus Sicht der Anwender beizutragen.
Jede ernsthaft betriebene Qualitätssicherung kommt nicht ohne einen Testplan aus. In der Agilen Entwicklung sollte man das Thema Testplan aber viel mehr als Modularen Baukasten betrachten, weniger als ein umfassendes Dokument was Zielkonstellationen definiert. Sicherlich muss klar werden, was das Ergebnis eines Testfalles ist um überhaupt feststellen zu können ob eine Produkteigenschaft erbracht wurde. Betrachtet man das den Testplan auf der Ebene einer User Story, erhält man einen Modularen Test Baukasten. Das Agile Team ordnet seine Aufgaben generell im Story-Format, also kann der Softwaretester sich der Methodik bedienen und einen Mini-Testplan für User Stories definieren. Hierfür eignet sich die Zeit in der Planungsphase und die ersten Tage eines Sprints. Es dauert ja bekanntlich immer ein wenig Zeit bis eine User Story umgesetzt wurde und für Test zur Verfügung steht.
Da der Softwaretester ein Bestandteil des Agilen Entwicklungsteams ist, nimmt er auch am Scrum Meeting Daily teil. Damit die Interaktion der Qualitätssicherung im Team visualisiert werden kann, sollte man das Scrum Board um eine Spalte „Test“ erweitern. Das Team kann dadurch gemeinschaftlich erkennen, welche Stories aus der Spalte „Work“ in die Hände der Qualitätssicherung umgeben wird. Der Softwaretester überprüft die einzelne Stories an Hand der bekannten Anforderungen im Backlog und der definierten Testfälle. Funktioniert eine User Story wie gewünscht hängt der Softwaretester die Storykarte vom Test in die Spalte „Done“. Wenn ein Fehler erkannt wird, muss der Softwaretester eine neue Bug-Karte erstellen und im Daily das Team über das Problem informieren. Es empfiehlt sich die Bug-Karte gemeinschaftlich mit der betroffenen User Story wieder in die Spalte „To Do“ zu hängen. Somit wird wiederum visualisiert, dass die User Story nicht erbracht wurde und durch die Bug-Karte wird klar, welches Problem besteht.
Um einen Fehler nachvollziehen zu können bedarf es meistens mehr Informationen als der verfügbare Platz auf einer Story-Karte hergibt. Viele Unternehmen arbeiten bereits mit sog. Bug-Tracking Systemen (wie Bugzilla, Jira, etc.). Dort sollten die Informationen zu einem Bug auch weiterhin verwaltet werden. Damit ein Bezug von der Bug-Karte auf dem Scrum Board zu dem Fall innerhalb eines ggf. eingesetzten Bug-Tracking Systems entsteht, ist es hilfreich die Identifikationsnummer (ID) des Falles auf der Bug-Karte zu notieren. Somit hat der betreffende Entwickler die Möglichkeit weitere Informationen zum gemeldeten Fehler abzurufen.
Am Ende eines Sprints sollte ein auslieferbares Inkrement bereitstehen. Durch die laufenden Tests im Sprint wurden die User Stories „isoliert“ auf korrekte Funktionsweise überprüft. Ein umfänglicher Softwaretest sollte aber auch Funktionalität aller User Stories im Zusammenhang abdecken. Dies setzt voraus, dass den Softwaretestern ausreichend Zeit nach einem Sprint zur Verfügung steht, um diese ganzheitlichen Tests durchzuführen. Es empfiehlt sich einen verkürzten Release-Sprint anzusetzen und die gleiche Scrum Methodik anzuwenden. D.h. es wird ein Daily durchgeführt an dem weiterhin das gesamte Agile Softwareteam teilnimmt. Wenn Bugs auftretten, müssen die Entwickler ja auch die Zeit haben die Fehler zu bereinigen. Zusätzlich benötigen die Softwaretester wiederum Zeit um die Regressiontests durchzuführen. Im Regelfall reicht es die Zeit für einen Release Sprint auf die hälft der Zeit eines regulären Sprints zu dimensionieren. Man sollte aber davon absehen eine dedizierte Planung für den Release Sprint durchzuführen. Es ist aussreichend den Release Sprint in der Gesamt Sprint Planung in der Gruppe zu diskutieren.
Wie immer bei Agilen Entwicklungsmethoden, muss man herausfinden ob eine vorbeschriebene Qualitätssicherungsmethode überhaupt anwendbar ist auf das Scrum Team. Jedes Unternehmen ist anders, jedes Teammitglied ist einzigartig und ob sich eine solche Verfahrensweise positiv auf das Ergebnis und auch die Interaktion im Entwicklungsteam auswirkt, kann nur die Realität aufzeigen. Frei nach der Maxime „Inspect & Adapt“ kann man es ausprobieren und im Rahmen der Retrospektive betrachten.