Testmanagement
In dieser Folge geht es darum, was Testmanagement in unserem (Agilen) Umfeld ist, wie man da hin kommt, warum es das nicht nur in der IT gibt und was es mit Psychologischer Sicherheit zu tun hat.
Auch Janina Kappelhoff ist wieder mit dabei! Wir (Henry Schneider & Janina) haben überraschender Weise ganz unterschiedliche Erfahrungen zum Testmanagement gemacht.
Diese Folge auf YouTube: https://youtu.be/B46TtWa3bUA
Wozu Testmanagement?
Braucht man das im Projektalltag?
Henry hat schon das ein oder andere, meist klassische, Projekt durchgeführt in dem das Testmanagement weggelassen wurde. Dann merkt man erst wofür es richtig gut gewesen wäre.
Die Qualität hat ganz schön darunter gelitten. Durch richtiges Testmanagement können wir also die Qualität unseres Produktes sicherstellen. Unsere Kunden erfahren sonst leider recht schnell, wenn wir hier schludrig waren.
Klar solche Produkte bleiben mehr im Gedächtnis, doch wollen wir das?
Was ist es?
Gerade in IT-Projekten ist Testmanagement bekannt und wenige Projekte oder Entwicklungen außerhalb der IT machen sich darüber Gedanken. Gleichzeitig gibt es dort trotzdem meist irgendeine Art von Ereignis, welches die Qualität eines Produktes absichert. In der haptischen Produktentwicklung kennen wir das vor allem. Beispielsweise eine Regenjacke, wo der Reißverschluss mehrfach getestet wird, bevor diese Jacke in großer Stückzahl produziert wird.
Bei Prozessen wird das Ganze natürlich deutlich unscheinbarer. Oder wenn das Produkt eine Dienstleistung ist. Da ist manchmal nicht so ganz klar, was Qualität denn eigentlich an der Dienstleistung ist und wer diese sicherstellt.
Auch wenn wir Prozesse entwickeln, so können wir diese testen. Henry macht dies gern initial mit 3 Dingen, die diesen Prozess einmal testweise durchlaufen. Einer normalen Sache und zwei Extrempunkten. Allein dies ist schon ein Test und fördert häufig schon Prozessschwächen hervor, an die vorher in der Theorie nicht gedacht wurde. Deshalb Testmanagement, denn nur theoretisch über den Idealfall nachzudenken reicht oft für die Realität nicht.
Janina hat gerade in den Beginnen ihrer Scrum Master Karriere festgestellt, wie wichtig Testmanagement für das Entstehen von Flow ist. Auch das Entstehen von Feedback und Lernen wird dadurch begünstigt. Wir empfehlen an der Stelle Das DevOps-Handbuch, welches sehr gut auf genau diese Themen eingeht.
In diesem Buch geht es auch um kontinuierliches Lernen und Experimentieren. Dafür braucht es Sicherheitsnetze und schon sind wir wieder beim Testmanagement. Dieses schafft Sicherheit und die damit verbundenen Setze im Unternehmen, Produkt und Team.
Durch das Sicherheitsnetz kommt das Wort Management auch ins Spiel. Wir dürfen schon vorbereiten, managen und das Ganze Netz wirklich als vertraute Sicherheit zur Verfügung stellen.
Hier gibt es, wie im Qualitätsmanagement, einen Produkttest und einen Prozesstest. Beides ist sowieso sehr eng miteinander verwoben, denn das Testmanagement stellt ja die Qualität sicher.
Früh testen
Weiterhin ist für uns Testmanagement auch das schauen auf nichtfunktionale Anforderungen. Oder was viele so nennen, denn meist sind es Qualitätsanforderungen oder Gesetze. Diese werden oft nicht explizit genannt, sondern erwartet. Das Testmanagement stellt sicher, dass dem auch wirklich so ist. Es ergibt auch Sinn solche Tests in Non-IT Bereichen zu schreiben.
Die hohe Kunst ist es ist jetzt das Testmanagement schon in jeden Entwicklungsschritt mit einzubinden. So früh wie möglich. Häufig sind sonst die Testerinnen die Personen, die das Produkt erst am Ende auf den Tisch bekommen und dann Änderungen recht teuer werden. Hier könnte man viel früher ansetzen und vielleicht sogar das Produkt schon so gestalten, dass es leichter testbar ist.
Je früher wir das hinbekommen, desto mehr kommen wir auch in Richtung Test Driven Development (TDD). Also dass es erst die Tests gibt und es wird nur noch gegen die Tests entwickelt. Sind diese grün, so sind wir fertig mit der Entwicklung. So können wir uns auch die Akzeptanzkriterien an den Stories sparen, da die Tests das Gleiche ausdrücken.
Wo ist Testmanagement im Agilen?
Wir wollen ja gerade kein Wasserfall mehr, sondern Testmanagement irgendwie mit dem Team verwurschteln.
Der erste Punkt, wo das Testmanagement schon drin steckt ist die Anforderungsbeschreibung. Natürlich auch das damit zusammenhängende Ritual Refinement. Im Artefakt der User Story steckt es da natürlich stark drin. Vor allem über die Akzeptanzkriterien. Wir verhandeln sprechen in der Routine schließlich darüber, wie später der Inhalt und auch das Ergebnis aussehen werden.
Dadurch ist das Testmanagement logischerweise auch im Review mit drin. Hier wird ja eigentlich überprüft. Natürlich ist es sogar noch besser, wenn eine erledigte Anforderung überhaupt erst ins Review geht, wenn diese – möglichst automatisiert – getestet wurde. Wäre ja auch ungünstig, wenn eine erledigte Anforderung das Review passiert hat, dann ins Testmanagement geht, Fehler gefunden werden und diese dann doch noch einmal im nächsten Sprint bearbeitet werden müsste. Wenn wir im Review feststellen, dass wir das anders erwartet hätten, fein, dann können wir direkt einen neuen Test für die Qualität aufnehmen. Deshalb machen wir ja auch Demos im Review.
Natürlich findest Du Qualität und Testmanagement sogar noch weiter vorn. Nämlich in der Definition of Done (DoD) und in der Definition of Ready (DoR).
So können wir uns, ganz im agilen Gedanken, auch immer mehr an gute Qualität und gute Test heraniterieren.
Das Wichtigste bleiben die crossfunktionalen Teams! Sprich, wir wollen das Testmanagement im Team integriert haben. Ja die bisherigen Testerinnen dürfen in das Team, als vollwertige Mitglieder, wandern.
Umsetzung
Da sind wir auch schon bei dem Punkt, dass wir im Agilen ja Entwicklungszyklen von wenigen Wochen haben und natürlich darin auch das Testmanagement haben wollen. In der Regel ist genau das am Anfang auch eine große Diskussion.
Gerade für die Testmanagementabteilungen löst die Crossfunktionalität auch ein Problem. Die Personaldecke. Gerade in klassischen Projekten gibt es eine Testphase kurz vor Projektende. Hierfür muss Personal vorgehalten werden. Und in der anderen Zeit? Genau, können diese Menschen bei den Produkten helfen, sich also in die Teams integrieren. 😉
Wir bekommen durch Crossfunktionalität auch viel früher Feedback und können dieses in die Produktentwicklung einfließen lassen.
Damit wir jetzt die Geschwindigkeit halten können, sollten wir auch diese Test automatisieren. Wichtiger Punkt für Flow, wiederkehrende Arbeiten wegautomatisieren.
Einführung mit Hindernissen
Henry stammt ja aus der IT und dort war es früher so, dass Betrieb (Test) und Entwicklung getrennt waren. Testen war die letzte Phase und wurde meist stark eingekürzt. Wenn man nun aber auch nur 1 Release pro Jahr hatte, so musste man mit den Testergebnissen überlegen ob man das nächste Release ein Jahr später nutzt oder die fehlerhafte Software released. Nicht so geil.
Dann hat Henry sein Entwicklerteam auf Scrum umgestellt und der Testabteilung plötzlich alle 2 Wochen eine neue Version übergeben. Die Test dauerten aber 6 Monate, bis dahin hat sich die Software deutlich weiterentwickelt und auch die Entwickler hatten kaum Bock in so alte Versionen noch einmal reinzugreifen. Zudem stapelten sich die Versionen plötzlich in der Testabteilung. Das hilft niemanden. Dann lieber trotzdem nur alle 6 Monate neue Versionen erzeugen oder noch besser das Testmanagement integrieren.
Die andere Lösung war, dass die Testabteilung auch einen zweiwöchigen Sprintzyklus bekommen hatte. Sie testen, was wir im letzten Sprint entwickelt haben und testen im nächsten, was wir diesen entwickeln. Auch nicht optimal und war trotzdem schon deutlich besser.
Get shit done,
Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du magst verlinke @znip_academy_agile und wir teilen deinen Like mit unseren Hörern.
Du möchtest dich von uns in der Tiefe in eurem Veränderungsprozess begleiten lassen, eure größten Komplexitätsnester auflösen und die besten Teamtipps bekommen? Dann buch uns 😉
In der Podcastfolge erwähnte Folgen zur Vertiefung:
- Qualität
- Teams
- Scrum Master
- Experimentieren
- Management überzeugen
- Vertrauten
- User Story
- Refinement
- Review
- Sprint
- Definition of Done (DoD)
- crossfunktional
- Agilität
Connecte dich gerne hier mit uns:
