Müssen QA-Tester ihre Sprints strikt befolgen?

Mein Entwicklerteam besteht aus:

2 Entwickler 1 QA-Tester 1 Scrum Master (ich)

Derzeit ist der QA-Tester Teil des Scrum-Teams, aber ich zwinge ihn nicht, einem strengen Sprint zu folgen, weil er nicht viel Arbeit hat. Wohingegen ich das Entwicklerteam vor Einmischung von außen schütze, da sie viel zu tun haben.

Da er erst nach getaner Arbeit aktiv ist, was in der Regel am Anfang oder Ende des Tages liegt, erledigt er in seiner Freizeit andere Aufgaben. Daher haben wir nur eine Zeit für den Beginn des Tages und das Ende des Tages für 1 Stunde festgelegt, um QA durchzuführen.

Ist das ok?

Lassen Sie sie Regressionstests durchführen. ihnen wird am Tag bald die Zeit ausgehen

Antworten (3)

Dies hängt weitgehend von Ihrem Arbeitsumfeld ab.

Meiner Erfahrung nach kann QA ein Team von 3-5 Entwicklern unterstützen, sodass Ihre QA definitiv nicht ausgelastet ist. Dies kann behoben werden, indem Sie Ihrem Team weitere Entwickler hinzufügen / die QA auf mehrere Teams verteilen.

Jenseits der Ressourcenzuweisung; Ihre QA kann mehr tun, als nur die im Laufe des Sprints gelieferte Funktionalität zu testen. Sie können:

  1. Schreiben Sie Testfälle für die Arbeit, die während des Sprints geliefert werden soll.
  2. Schreiben Sie Automatisierungstests für die Anwendung
  3. Richten Sie Testdaten für den aktuellen Sprint ein
  4. (Traditionell nicht berücksichtigt) Beziehen Sie die Qualitätssicherung in die Anforderungserfassung/Sprint-Vorplanung ein, da sie oft in der Lage sein wird, Lücken in den Stories zu stechen, die nicht berücksichtigt werden.

Es kann sich lohnen, diese Frage auch auf der Q&A-Website zu Software Quality Assurance & Testing zu stellen.

Ich stimme zu, dass QA ihre Aktivitäten abhängig von ihren Fähigkeiten erweitern kann, aber ich weiß nicht, wie Sie zu dem Ergebnis gekommen sind: "QA kann ein Team von 4+ Entwicklern unterstützen". Jedes Projekt unterscheidet sich von der Technologie, den Anforderungen und den beteiligten Personen, und ich denke, wir sollten solche Verallgemeinerungen nicht vornehmen.
Er ist ein Usability-Tester, kein Tester, der Code schreibt, dh ein Automatisierungstester. Das heißt, er kann die Funktionalitäten erst testen, wenn das Entwicklerteam sie geschrieben hat.
@bobo2000: Das schließt nur Punkt 2 der möglichen Mehrarbeit aus. Und Sie können den Tester jederzeit fragen, ob er bereit ist, das zu lernen (möglicherweise einfacher, wenn die Testautomatisierung ein eher übergeordnetes Framework verwendet, in dem es sich nicht so anfühlt, als würden Sie Code schreiben).
@MasterPJ Die Aussage basiert auf meiner Erfahrung in der Arbeit mit Scrum-Teams. Ich habe die Aussage geändert, um diese Erfahrung genauer widerzuspiegeln.

Scrum-Teams sollten funktionsübergreifend arbeiten. Wenn Tester erst testen, nachdem die Entwicklung abgeschlossen ist, hinken sie hinterher. Dies könnte zu Situationen führen, in denen die Arbeit am Ende des Sprints „erledigt“, aber nicht getestet ist. Jetzt testet der Tester es im nächsten Sprint? und die Probleme werden adhoc behoben? Dies entfernt den gesamten Fokus auf eine Sprint-Idee.

Was Sie vorschlagen, klingt wie ein Mini-Wasserfall , bei dem Disziplinen aufeinander warten.

Tester sollten parallel zum Team die Tests vorbereiten und vorzugsweise automatisiert durchführen. Wenn die Arbeit erledigt ist, sollte jeder in der Lage sein, die fertige Arbeit zu überprüfen/testen. Tun Sie dies, bevor jemand mit neuer Arbeit beginnt, beenden Sie User Story für User Story mit dem gesamten Team. Entwickler können auch testen und Tester können auch codieren, UX ausführen, dokumentieren oder andere erforderliche Aufgaben ausführen, um eine User Story fertigzustellen. Setzen Sie den Tester als Testexperten im Team ein, anstatt allein für das Testen verantwortlich zu sein. Für die Qualität ist das Team verantwortlich, nicht nur der Tester.

Lesen Sie das Buch „ Agile Testing “ oder lassen Sie Ihre Tester den Kurs „ Certified Agile Tester“ absolvieren .

Der Tester in meinem Team ist ein Usability-Tester, er schreibt nicht wirklich Code, dh automatisierte Tests usw. Eigentlich ist er nicht einmal darin ausgebildet.
Er testet also nur die Usability? und nichts funktionsfähig? Sie nannten ihn in Ihrer Frage etwas verwirrt einen QA-Tester. Aber in seiner/ihrer aktuellen Ausfallzeit könnte er versuchen, sich selbst zu lernen, oder ich würde anfangen, nach einem anderen Tester zu suchen, der das kann. Jemand, der nur ein manueller Tester ist, passt nicht in ein kleines Scrum-Team, wenn Sie mich fragen.
Yep das ist, was ich tue. In seiner Freizeit erledigt er andere Aufgaben, die nichts mit der Arbeit des Entwicklerteams zu tun haben.

In Scrum gibt es keine Rolle als Tester. Im Scrum Guide steht geschrieben:

Scrum erkennt keine Titel für andere Mitglieder des Entwicklungsteams als Entwickler an, unabhängig von der Arbeit, die von der Person ausgeführt wird; es gibt keine Ausnahmen von dieser Regel;

Sie sollten die QA innerhalb des Sprints halten, um sicherzustellen, dass Sie nach jedem Sprint ein potenziell veröffentlichungsfähiges Produkt haben . Ohne QA wird das Testen nicht durchgeführt und das Inkrement wird nicht durchgeführt.

Darüber hinaus, indem Sie die Arbeit an Features einzeln und nicht parallel erzwingen und am Ende des Sprints alle auf einmal fertigstellen

  • Ihre QA hätte die ganze Zeit etwas zu tun,
  • Das Entwicklungsteam wird Fehler früher entdecken und Zeit haben, sie zu beheben
  • Das Entwicklungsteam hat eine bessere Kontrolle darüber, was fertig gestellt werden kann und was nicht

Falls für die QA noch etwas Freizeit bleibt, sollte sie/er ihre/seine Fähigkeiten verbessern, um bei anderen Aktivitäten nützlicher zu sein.

Wenn QAs Spezifikationsänderungsfehler in laufenden Arbeiten melden, kann dies einen Sprint zunichte machen
@Ewan Was meinst du? Zu Beginn des Sprints sollten alle Personen verstehen, was das Ergebnis jeder User Story sein soll. Kannst du etwas genauer werden?
Waren Sie noch nie in der Situation, dass die QA „Bugs“ meldet, die zwar absolut gültige Kommentare sind, aber nicht in der Spezifikation stehen. dh "sollte das Menü diese Farbe haben, kollidiert es mit dem Hintergrund", wenn die Menüfarbe nicht angegeben wurde. Der PO wird zustimmen, dass er Recht hat, und der Fehler wird in die Mitte des Sprints verschoben, aber effektiv ist es zusätzliche ungeplante Arbeit
Sicher, diese Dinge passieren. Von Zeit zu Zeit haben wir vergessen, etwas anzugeben oder etwas nicht zu erkennen, und es taucht während des Sprints auf und verursacht zusätzliche unerwartete Arbeit. Aber ich denke, das ist normal, das kann man nicht vermeiden, egal was man tut. Darüber hinaus ist jedes Mal, wenn dies geschieht, ein potenzieller Punkt zum Lernen. Und je früher die QA mit dem Testen beginnt, desto eher wissen wir Bescheid. Es würde nicht helfen, das Feature gemäß der Spezifikation fertigzustellen, wenn es nicht funktionieren würde.
Der richtige Weg ist, das neue Feature dem nächsten Sprint hinzuzufügen. Sicher, das Schreiben der Spezifikation ist schwierig, aber der Sinn des Sprintens besteht darin, die Dinge in Schritten zu erledigen. Wenn Sie nur abgeschlossene Geschichten testen, wird dies erzwungen
Müssen QA-Tester ihre Sprints strikt befolgen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v