Wir haben drei Teams, die an demselben Produkt arbeiten. Derzeit werden unsere automatisierten Systemtests von zwei QA-Leuten geschrieben, die sehen, was in den Reviews fertig ist, und dann entsprechende Tests schreiben.
Das hat gut funktioniert, aber wir drängen jetzt auf Continuous Deployment und müssen sicherstellen, dass die Systemtests während des Sprints geschrieben werden, damit wir sofort Regressionstests durchführen können. Da derzeit keines der Teams die Funktion vollständig besitzt, ist unklar, wer für die Systemtests verantwortlich sein soll.
Der Scrum-Leitfaden besagt, dass ein Scrum-Team über alle erforderlichen Fähigkeiten verfügen sollte, um ein Produktinkrement zu liefern.
Die Idee ist, dass ein Team ein oder mehrere Features nimmt und sie bis zum Ende eines Sprints vollständig implementiert. Scrum-Teams besitzen die Funktionen, an denen sie arbeiten, und dazu gehören Systemtests und -bereitstellung.
Wenn Sie mehrere Scrum-Teams haben, die an demselben Produkt arbeiten, ist es üblich, dass jedes Team an einem Funktionsthema arbeitet (z. B. könnte ein Team an Sicherheitsfunktionen und ein anderes an Personalisierungsfunktionen arbeiten).
Unabhängig davon, wie die Arbeit zwischen den Teams aufgeteilt wird, ist der Ansatz derselbe. Jedes Team übernimmt die volle Verantwortung für die Bereitstellung eines Features, bis es möglicherweise veröffentlicht werden kann .
In Ihrer Situation würde ich vorschlagen, dass Sie Folgendes berücksichtigen:
Möglicherweise möchten Sie auch die Art und Weise, wie Sie Ihre automatisierten Tests durchführen, überdenken. Viele automatisierte Tester, mit denen ich zusammengearbeitet habe, beginnen mit den Tests gleichzeitig mit dem Entwicklungsstart. Sie warten nicht, bis die Entwicklung abgeschlossen ist, bevor sie mit der Erstellung der automatisierten Tests beginnen.
Ein gängiger Ansatz besteht darin, dass die Entwickler schnell ein Stub-Release erstellen, das die Funktion nachahmt, die sie gerade entwickeln werden. Die Tester beginnen dann sofort damit, einen Test zu schreiben. Sobald die Entwickler die Entwicklung abgeschlossen haben, tauschen sie den Stub aus und ersetzen ihn durch den echten Code.
Vieles hängt von Ihrem skalierten Framework ab, aber im Allgemeinen lautet die Antwort, dass jedes einzelne Scrum-Team für das Testen seiner eigenen Arbeit verantwortlich ist. Wenn Sie beispielsweise Nexus verwenden :
Die Scrum-Teams sind für die Entwicklung von Inkrementen potenziell veröffentlichbarer Software verantwortlich, wie in Scrum vorgeschrieben. [Hinweis: Ein abgeschlossenes Inkrement sollte die vollständige Definition of Done umfassen, einschließlich des Testens des Inkrements. ]
Das Nexus-Integrationsteam übernimmt alle Integrationsprobleme. Es ist verantwortlich für die erfolgreiche Integration aller Arbeiten aller Scrum-Teams in einem Nexus. Die Integration umfasst die Lösung aller technischen und nicht-technischen teamübergreifenden Einschränkungen, die die Fähigkeit eines Nexus beeinträchtigen können, ein konstant integriertes Inkrement bereitzustellen. [NB: Das Testen der Inkremente jedes Scrum-Teams für sie ist keine teamübergreifende Funktion, die zum Nexus-Team gehört. Der eigentliche Fokus eines Nexus liegt auf der Integration zwischen Teams. ]
In Nexus kann es Mitglieder des Nexus-Teams geben, die dafür verantwortlich sind, die Integration der Arbeit zwischen den Teams zu testen. Die Annahme ist jedoch, dass jedes Scrum-Team funktionale, getestete Arbeit liefert, die in das Nexus-Inkrement integriert werden soll.
Wenn Sie versuchen, Kosten einzusparen oder eine Art operative Abkürzung zu nehmen, indem Sie Testaktivitäten auslagern, folgen Sie nicht einem skalierten Scrum-Ansatz. Zu diesem Zeitpunkt folgen Sie noch nicht einmal agilen Best Practices. Stattdessen machen Sie einen Schritt zurück von integrierten, funktionsübergreifenden Teams hin zu einem traditionelleren Wasserfallansatz, bei dem Entwicklung und Qualitätssicherung separate und aufeinander folgende Funktionen sind.
Tu das nicht.
Wer sollte für das Schreiben der automatisierten Tests verantwortlich sein?
Der Entwickler, der den Code schreibt. und vorzugsweise , bevor der Produktionscode geschrieben wird.
Nennen Sie mich einen TDD-Eiferer, wenn Sie möchten, aber ich konnte den Unterschied in der Testabdeckung zwischen dem Code, den ich in TDD geschrieben habe, und dem, als ich die Tests schrieb, nachdem der Code fertig war, messen. Die Branchenabdeckung ist in meiner zugegebenermaßen unwissenschaftlichen Forschung (mit einer zugegebenen Stichprobengröße von 1 Entwickler) um ~20% besser.
Andreas
Friedrich Wendt