Der Tester als nachträglicher Requirements Engineer im agilen Embedded-Projekt
Gegen Stories zu testen sorgt für erheblichen Aufwand im Testmanagement, der bei großen Projekten nicht tragbar ist. Erheblich effektiver ist es, Tests gegen eine Produktspezifikation zu schreiben. Liegt diese in einem agilen Projekt nicht vorab vor, kann sie nach und nach auf Basis der Stories entstehen. Je früher sie im Sprint geschrieben wird, desto besser. Da ihr Nutzen erstmals beim Tester offensichtlich wird, bleibt die ungeliebte Arbeit oft an ihm hängen. Der Tester wird damit zum nachträglichen Requirements Engineer.
In diesem Praxisvortrag berichten die Referenten aus einem laufenden Embedded-Projekt, in dem acht agile Teams gemeinsam ein Produkt entwickeln. Die Tester erstellen dabei nachträglich auf Basis der Stories eine Produktspezifikation und testen gegen diese Spezifikation.
Der Vortrag gibt Antworten auf die folgenden Fragen: Warum sollte man gegen Stories testen? Und warum nicht? Was war die Motivation dafür, die Vorgehensweise zu ändern?
Was lernen die Zuhörer in dem Vortrag?
Wie organisiert man im agilen Projekt mit acht Scrum-Teams die Testentwicklung, wenn Requirements vorab fehlen oder kaum vorhanden sind?
Fortgeschritten
Zeit
12:15-13:00
03. Juli
Raum
Raum "Rom"
Zielpublikum
Mitarbeiter in agiler Embedded-Entwicklung, vor allem mit mehreren Scrum-Teams
Themengebiet
Agile Testing
ID
Mi3.2