Embedded Testing in Scrum
2012
Als Teammitglied mit dem Fokus Testing im Scrum Team drin. So macht es meiner Meinung nach Sinn. So sind die Wege wirklich kurz, Bugs werden gefunden und gefixt mit minimalem Overhead und ich bin als Tester wirklich embedded – mitten im Team drin. Soweit die guten Neuigkeiten.
Die Schwierigkeiten, die wir zuvor mit konventionellen Testphasen nach der Implementierungsphase hatten, sind aber natürlich nicht verschwunden. Wie erfahre ich, was wirklich implementiert wurde und was Req Engineering und Entwicklung noch bilateral abgesprochen haben? Wie vermeide ich Doppelspurigkeiten zwischen Test auf verschiedenen Stufen – üblicherweise Integrationstest, die der Entwickler in JUnit schreibt und meinen automatisierten Systemtest?
Basierend auf einem Workshop bei Janet Gregory haben wir zwei Synchronisierungspunkte in unserem Prozess eigeführt zwischen dem Entwickler und dem Tester eines bestimmten Features:
Das Meeting “Share-Test-Ideas” zur Absprache, wer welche Tests macht. Diese Synchronisierung findet bevor oder zu Beginn der Umsetung eines Features statt.
Und dann noch die “Show-Me-Session” sobald das Feature testbar und im Nightly Build drin ist, um zu besprechen, was nun wirklich realisiert wurde.
Diese Klammer um die Umsetzung bewirkt zwar keine Wunder, bringt aber enorm viel für die Zusammenarbeit und die Effizienz.
Im März 2012 werde ich am Swiss Testing Day einen kurzen Vortrag zu diesem Thema halten: Überleben als Embedded Tester im Scrum Team -Heisse Drähte, enge Verknüpfungen und gordische Knoten
Comment