QAs erhalten die gesamte Arbeit am Ende des Sprints

Sie sollten die Entwicklung und das Testen nicht als aufeinanderfolgende Aktivitäten innerhalb des Sprints betrachten, da sonst das, was Sie beschreiben, passiert. Entwicklung und Test sollten gemeinsam als Zusammenarbeit zwischen Entwicklern und Testern erfolgen. Es erfordert eine Veränderung Ihrer Arbeitsweise. Weitere Details finden Sie hier: Was macht ein QA-Team während der Entwicklungsphase eines Sprints in Agile Scrum?

Bis Sie diese Art von Änderung einführen, sollten Sie die PBIs zumindest in kleine Stories aufteilen, die Sie entwickeln und sofort testen, anstatt bis zum Ende des Sprints zu warten (dh den Abstand zwischen den Entwicklungs- und Testaktivitäten so weit wie möglich zu reduzieren). .

Ja. Eine gängige Faustregel für einen zweiwöchigen Sprint lautet, dass die meisten Backlog-Elemente 2–3 Tage in Anspruch nehmen sollten, einschließlich QA, Bereitstellung usw. Dies ist jedoch nur eine Weisheit für erfahrene Teams, keine feste Regel. Es wird auch Zeit brauchen, um dorthin zu gelangen. Wenn das Team daran gewöhnt ist, dass ein Backlog-Element volle 2 Wochen in Anspruch nimmt, werden sie nicht sofort auf 2 Tage springen.

Es gibt drei Praktiken, die ich in Betracht ziehen würde, um Ihrem Team zu helfen:

1. Backlog Items im Nachhinein aufschlüsseln. Es ist üblich, dass das Team nicht weiß, wie es Backlog-Elemente aufschlüsseln soll, wenn sie beginnen. Eine gute Möglichkeit, etwas zu lernen, besteht darin, eine kurze Diskussion zu führen, sobald das Element fertig ist, und die Frage zu stellen: „Wenn ich mit dem Wissen, was ich jetzt weiß, in der Zeit zurückgehen könnte, wie könnte ich das kleiner aufschlüsseln.“ Sie können diese Lektionen dann in Zukunft zu ähnlichen Artikeln mitnehmen.

2. Verlagern Sie Tests und Qualitätssicherung früher in den Entwicklungsprozess. TDD, ATDD und BDD sind großartige Möglichkeiten, einen großen Teil des Testens vor die Entwicklung zu verlagern und den Entwicklungsprozess zu rationalisieren. Diese fühlen sich zu extrem an, versuchen Sie es mit einem einfachen Treffen mit drei Freunden. Bei diesen Treffen führen ein Programmierer, ein Tester und ein Unternehmens-/Benutzervertreter ein Gespräch, bevor die Arbeit beginnt. Dadurch werden viele der Test- und Funktionalitätsideen auf den Tisch gebracht, bevor eine Codezeile geschrieben wird, und das Hin- und Her-Übergeben wird erheblich reduziert.

3. Zu einer Gruppe zusammenschließen! Von allen Teams, mit denen ich zusammengearbeitet habe, kommt das Problem, das Sie beschreiben, fast immer von Leuten, die bei der Arbeit einen Teile-und-Herrsche-Ansatz anwenden. Dieser Ansatz ist im ersten Durchgang in der Regel zeiteffizienter, verliert jedoch viel mehr Zeit für die Integration, den Wissensaustausch und das Testen. Wählen Sie ein oder zwei Elemente aus und gruppieren Sie sie mit dem Fokus darauf, wenige Elemente schnell fertigzustellen, anstatt viele Elemente zu beginnen.

Jedes davon wird helfen, aber sie können auch zusammen verwendet werden. Viel Glück!

Es gibt verschiedene Möglichkeiten, dieses Problem anzugehen.

Aus Scrum-Perspektive hat Ihr Entwicklungsteam keine Unterteams. Möglicherweise haben Sie Spezialisten, z. B. Personen, die sich auf Tests spezialisiert haben, aber das gesamte Team sollte beteiligt sein. Anstatt die QA-Spezialisten in eine Position zu bringen, in der sie am Ende des Sprints alles testen müssen, sollte das gesamte Team in die Tests einbezogen werden, wann immer diese Tests stattfinden. Die QA-Spezialisten können dabei helfen, den Rest des Teams in bewährten Testverfahren zu schulen.

Nicht spezifisch für Scrum, die Arbeit schrittweise während des Sprints zu liefern und sie kontinuierlich zu integrieren und zu testen, würde auch dazu beitragen, den Druck etwas zu verringern. Anstatt am Ende des Sprints zu testen, testen Sie nach Abschluss der Arbeit. Wenn Sie bis zum Ende des Sprints warten, um die Arbeit zu integrieren, versuchen Sie, sie früher zu integrieren. Wenn es so aussieht, als ob Sie es nicht können, könnte dies ein Zeichen dafür sein, dass Ihre Arbeit nicht die richtige Größe oder Aufteilung hat.

Schließlich kann es in manchen Umgebungen gute Gründe für eine unabhängige Qualitätssicherung geben. Die ersten beiden Punkte gelten immer noch, und das Entwicklungsteam sollte ein qualitativ hochwertiges Produkt produzieren. Unabhängige Integrationen und Tests sollten jedoch aus dem Sprint heraus und in ein separates Team verschoben werden. Wenn das Entwicklungsteam gute Arbeit geleistet hat, hat dieses Team möglicherweise Feedback, sollte aber nicht regelmäßig Probleme finden, die verhindern würden, dass die Ausgabe eines Sprints für den nächsten nachgelagerten Prozess freigegeben werden kann.

Da diese Frage ein exaktes Duplikat einer Frage im Software Quality Assurance & Testing Stack Exchange ist , ist dies ein exaktes Duplikat meiner Antwort dort, da sie gleichermaßen anwendbar ist.

Versuchen Sie zunächst, die Ursache des Problems zu ermitteln. Ich kann einige mögliche Ursachen vorschlagen:

1. Sprints sind zu lang. Fünf bis zehn Arbeitstage sind eine gute Länge für einen Sprint. Das Problem bei Sprints mit längerer Dauer besteht darin, dass die Schätzung tendenziell schwieriger ist, das Team sich eher überfordert, zu viele Kontextwechsel durchführt und dann auf unvorhergesehene Probleme stößt.

2. Unerwartete Arbeit. Auch dies kann durch zu lange Sprints verursacht werden, was bedeutet, dass unerwartete Elemente auftreten, die angegangen werden müssen, bevor der Sprint abgeschlossen ist. Auch Probleme mit dem Ressourcenmanagement und der Priorisierung können ein Faktor sein.

3. Fehlerhafte Schätzung. Das Team muss während der Sprintplanung prognostizieren, was es während eines Sprints realistisch erreichen kann. Vermeiden Sie absolute Schätzungen (Tage und Stunden). Wenn das Team das Bedürfnis verspürt, Backlog-Items numerisch zu bewerten, verwenden Sie die relative Schätzung (Punkte). Die vorherige Sprintgeschwindigkeit ist ein guter Anhaltspunkt dafür, was erreicht werden kann, aber es ist nur ein Anhaltspunkt, und das Urteil des Teams ist wichtiger als die Zahl, die es für die Geschwindigkeit angibt. Wenn Sie in einem Sprint häufig unerledigte Aufgaben haben, deutet dies darauf hin, dass das Team nicht basierend auf seiner bisherigen Leistung inspiziert und sich anpasst.

4. Fehlende Testautomatisierung. Das Erstellen von Tests kann und sollte parallel zur Codeentwicklung erfolgen. Wenn Sie Ihre Tests erstellt und ein geeignetes Automatisierungs-Framework eingerichtet haben, sollte die automatisierte Ausführung sehr wenig Zeit in Anspruch nehmen.

5. Schwache DoD-Disziplin. Die Definition of Done bedeutet, dass eine Story entweder zu 100 % fertig ist (Testen natürlich eingeschlossen) oder zu 0 % fertig ist. Das Team sollte sich selbst organisieren, um sicherzustellen, dass alle DoD ernst nehmen.

Mein Vorschlag wäre:

• Investieren Sie mehr in automatisierte Regressionstests
• Machen Sie das Problem zu einem Teil Ihres Planungsprozesses: "Mit welchem ​​Ticket sollten wir zuerst beginnen, damit wir es so früh wie möglich im Sprint testen können?"