Hilfe der QA in den ersten Sprinttagen eines Sprints

Gemäß der Agile-Philosophie ist es wichtig, dass das Team als Einheit zusammenarbeitet, um das zu Beginn einer Iteration festgelegte Ziel zu erreichen. Vor diesem Hintergrund weiß ich, dass Entwickler und Analysten der QA am Ende einer Iteration helfen können, um sicherzustellen, dass alle Tests rechtzeitig abgeschlossen werden.

Wie kann die QA dem Team zu Beginn eines Sprints helfen, wenn keine Storys abgeschlossen sind und die Testpläne fertig sind?

(Wir sind ein Team von 5-6 Personen mit 1 QA und wir befinden uns in 3-Wochen-Sprints, sodass die Totzeit für die QA lang sein kann.)

Antworten (3)

QA sollte niemals zu einem separaten Prozesspfad werden

Die Qualitätssicherung (QA) ist ein integraler Bestandteil des agilen Lieferprozesses. Das Bestehen von Tests ist oft ein formaler Bestandteil der Definition of Done, und Test-Driven Development (TDD) ist eine gängige Praxis, die ihren Ursprung in Extreme Programming hat und von anderen agilen Frameworks weitgehend übernommen wurde.

Die QA-Spezialisten in einem funktionsübergreifenden Team haben vom ersten Tag an eines Sprints mehrere Möglichkeiten, einen Beitrag zu leisten:

  1. Sie müssen beim Schätzen von Storys helfen, da der Zeit- und Arbeitsaufwand für das richtige Testen Teil der Story-Point-Schätzung sein muss.
  2. Sie sollten mit den Entwicklern zusammenarbeiten , um sicherzustellen, dass Einheiten- und Akzeptanztests in den Prozess des Teams integriert werden.
  3. Sie können Geschichten vor den Entwicklern behandeln, um sicherzustellen, dass neue Funktionen geschrieben werden, um definierte Akzeptanztests zu bestehen.
  4. Sie können Stories mit den Entwicklern bearbeiten, um sicherzustellen, dass alle neuen Arbeiten auf Unit- und Integrationstestebene vollständig testbar sind.
  5. Sie können mit den Entwicklern paarweise programmieren, so dass sich die Entwickler und Tester gegenseitig befruchten, ihr spezielles Fachwissen teilen und den Wissenstransfer innerhalb des funktionsübergreifenden Teams verbessern.

Während alle oben genannten Beispiele am stärksten auf Softwareprojekte zutreffen, ist das gleiche allgemeine Konzept weitgehend auf Fertigungs- oder Geschäftsprozessprojekte übertragbar. Jeder im Team hat etwas beizutragen, und die besten Teams „werfen niemals etwas über die Wand“ gegenüber anderen Teammitgliedern; die Arbeit sollte immer kollaborativ bleiben.

Sehr interessante Punkte. Es sieht aus wie etwas, das eine Weile dauern könnte, bis es vollständig in die tägliche Arbeit integriert ist, aber es ist sicherlich einen Versuch wert. Vielen Dank.

In einigen Teams kümmern sich die Tester um die Implementierung automatisierter Akzeptanztests, während die Programmierer an der Implementierung der neuen Funktionen arbeiten. In anderen Fällen beginnen sie mit der Vorbereitung von Testdaten oder Testskripten, die verwendet werden, sobald die neuen Storys in den Build aufgenommen werden.

Manchmal wissen Programmierer nicht genau, welche Auswirkungen die neue Funktion haben wird. Tester können helfen, indem sie explorative Tests durchführen, die neue Funktionalität simulieren oder ähnliche Szenarien, um den Programmierern vorab Feedback zu geben. Oder sie können mit Geschäftsanwendern sprechen, um weitere Erläuterungen zu ihren Erwartungen zu erhalten oder Ideen zum Testen kniffliger Eckfälle zu erhalten.

Darüber hinaus könnten Tester aber auch Entwicklungsaufgaben übernehmen und sich in anderen Fachgebieten lateral weiterentwickeln. Eine gute Möglichkeit, dies zu tun, besteht, wie in einer anderen Antwort erwähnt, darin, sich mit Programmierern zu paaren.

Ich hatte dieses Problem auch. Eine große Sache, die wir gemacht haben, war ein hartes WIP-Limit für die Entwickler. Dies zwang sie dazu, Geschichten früher im Sprint zu beenden, bevor sie zu einer anderen übergingen. Dies bedeutet dann, dass die QA früher im Sprint mit dem Testen beginnen kann, um einen riesigen Engpass gegen Ende des Sprints zu vermeiden.