Üblicherweise steht am Ende eines Sprints ein “potentially releasable Increment of "Done" product”. Ein ungetestetes Produkt zu veröffentlichen ist in den wenigstens Fällen akzeptabel, erst recht, wenn es um embedded Produkte geht.

Beim embedded testing besteht eine Erschwernis darin, dass manche Tests erst ausgeführt werden können, wenn ein selbst entwickeltes Testsystem (Hardware, Software) zur Verfügung steht.

In diesem Praxisvortrag stellen die Referenten ein laufendes Projekt vor, in dem die Produktentwicklung und die Entwicklung des Testsystems organisatorisch zunächst relativ stark voneinander isoliert stattfanden. Daraus entstanden lange zu Entwicklungszeiten für neue Produktfeatures. Der Vortrag zeigt anschließend auf, wie die Entwicklung des Testsystems für die agile Testentwicklung in die Sprintplanung mit acht Scrum-Teams integriert wurde und welche Effekte daraus resultierten. Der Schlüssel besteht darin, die Test-Hardware/-Software als gleichberechtigt mit der Produkt-Hardware/-Software zu behandeln. Dadurch verringern sich Abstimmungsaufwände zwischen Produkt- und Testsystem-Entwicklung.

Der Vortrag gibt Antworten auf die folgenden Fragen: Wie lief die Entwicklung des Test-Systems vor der Veränderung ab? Worin bestand die Veränderung genau? Welcher Nutzen und welche Hindernisse sind aufgetreten?

Was lernen die Zuhörer in dem Vortrag?

Wie kann man große Embedded-Projekte mit mehreren Scrum-Teams organisieren, damit die erforderliche Entwicklung von Test-Hard-/-Software nicht zu unnötigen Verzögerungen führt?