Kann die QA laufende Aufgaben testen? Wie werden Fehler bei unvollständigen Geschichten gemeldet?

Ich wurde kürzlich in ein neues Team versetzt. Es gibt viele Praktiken, die meiner Meinung nach nicht mit dem Scrum Guide übereinstimmen, aber jetzt möchte ich zwei seltsame Praktiken besprechen.

  1. Während wir Entwickler an Aufgaben arbeiten, beginnen die Mitarbeiter der Qualitätssicherung damit, sie anhand so vieler Szenarien zu testen, wie sie sich vorstellen können. Anschließend fügen sie alle gefundenen Probleme als Fehler hinzu. Jeder vernünftige Mensch würde sagen, dass dies falsch ist. Wenn Sie der Meinung sind, dass ein Entwickler einen Fall oder ein Szenario vermissen könnte, können Sie diese in der Beschreibung der Aufgabe hinzufügen oder eine Unteraufgabe erstellen.

Ich habe diesen Punkt mit den QAs und dem Agile Coach angesprochen und die Antwort war, dass Scrum es uns erlaubt, bestimmte Dinge zu ändern, wenn wir aus Erfahrungen lernen, also haben wir diese Sache eingeführt. Ich möchte wissen, ob diese Praxis richtig oder falsch ist. Ich kann nichts Praktisches dagegen tun, außer das Thema in der Retrospektive anzusprechen.

  1. Die zweite Frage betrifft das Testen abgeschlossener Aufgaben. Ein Entwickler erledigt seine Aufgaben, sagen wir 4 Tage vor dem Ende des Sprints. Die QA findet, dass etwas in der Implementierung fehlt. Sollte es als Fehler gemeldet werden oder sollte die Aufgabe einem Entwickler neu zugewiesen werden , mit einem Kommentar oder einer Bearbeitung in der Beschreibung und zurück in den Fortschritt verschoben werden?

Wenn die QA in unserem Team derzeit ein Problem mit der Aufgabe findet, behalten sie die Aufgaben im Test, fügen aber einen neuen Fehler als Sub hinzu und weisen sie dem Entwickler zu.

Meine Frage: Ist dieser Ansatz richtig? Beispielsweise gibt es eine Aufgabe, die Farbe von zwei Schaltflächen zu ändern, eine sollte jetzt grün und die andere rot sein. Ein Entwickler arbeitet an dieser Aufgabe, er versteht zuerst die Aufgabe. Wie sollten sie dies tun, CSS oder JavaScript verwenden (dies ist nur ein einfaches Beispiel, also haben Sie bitte etwas Geduld)? Sie ändern nur eine Taste oder vergessen, eine andere Taste zu ändern, oder ändern beide, aber aufgrund schlechter Codierung wird nur eine geändert. Jetzt verschiebt der Entwickler diese Aufgabe zum Testen, die QA testet die Aufgabe und stellt fest, dass nur eine Schaltfläche geändert wurde. Soll das Problem nun an den Entwickler zurückgesendet oder ein Bug gemeldet werden?

  • Wenn das Problem zurückgegeben wird, weiß der Entwickler bereits, wie man die Farbe ändert, er wird das Problem beheben, es wird schnell gehen.
  • Wenn ein Fehler gemeldet wird und der Fehler einem anderen Entwickler zugewiesen wird, ist das Zeitverschwendung. Der neue Entwickler muss sehen, wie er die Aufgabe besser erledigen kann. Ein fehlendes Semikolon könnte der Grund sein.

Nun meine Frage: Was ist der bessere Ansatz für die beiden oben genannten Fälle?

Antworten (2)

Das Entwicklungsteam sollte über alle erforderlichen Fähigkeiten verfügen, um Backlog-Elemente in Inkremente funktionierender Software umzuwandeln. Damit dies wahr ist, müssen sie über die Fähigkeiten verfügen, alle Tests im Team während des Sprints zu absolvieren.

Separate QA ist sinnlos, wenn Ihr Entwicklungsteam funktionierende Software erstellt. Es hört sich so an, als gäbe es in Ihrem Team eine Lücke, wo der Test sein sollte. Ich würde dies bei der Retrospektive ansprechen und versuchen herauszufinden, warum Sie eine „Wir gegen Sie“-Dynamik zwischen dem Entwicklungsteam und QA-Mitarbeitern haben.

Einige Anleitungen:

  1. Funktionsübergreifendes Team – es sollte keine Unterteams geben, sondern nur eine Gruppe von Einzelpersonen mit allen erforderlichen Fähigkeiten, die für die Erstellung funktionierender Software verantwortlich sind.
  2. Backlog Items sollten minimal, aber ausreichend sein – gibt es genügend Informationen, dann gibt es weniger Überraschungen. Ich würde erwarten, dass Testfälle als Teil des Refinement-Prozesses definiert werden. Ich würde auch erwarten, dass ein Entwicklungsteam befugt ist, Elemente in der Sprintplanung abzulehnen, wenn sie nicht ausreichen.
  3. In Sprint-Bugs – Probleme, die innerhalb des Sprints gefunden werden, sollten ein Gespräch zwischen den Mitgliedern des Entwicklungsteams sein und sofort behoben werden. Wenn das Problem das Sprintziel gefährdet, ist möglicherweise ein Gespräch mit dem PO angebracht.
  4. Out-of-Sprint-Bugs – Wenn Sie Probleme in der Ausgabe des Sprints finden, sollten Sie einen Bug erstellen und ihn verfolgen, ihn dann bei der Sprint-Retrospektive diskutieren und beheben.
  5. extern identifizierte Probleme – jede Arbeit, die von einem Team, einer Gruppe oder einer Person außerhalb des Entwicklungsteams identifiziert wurde, sollte diese Arbeit vom Product Owner angeordnet und priorisiert haben. Jede neue Arbeit, die in den Sprint kommt, kostet den Product Owner Geld und ist für das Unternehmen möglicherweise nicht so wertvoll wie etwas anderes.

Fragen für deine Retro:

  1. Warum gibt es zwischen Entwicklung und Test ein Wir-gegen-sie-Gefühl?
  2. Warum meldet das QA-Team Fehler in der Sprintarbeit, wenn ein Gespräch besser wäre?
  3. Warum gibt es ein QA-Team?
  4. Ist unsere Definition von Done ausreichend?
  5. Warum fügt QA Arbeit direkt zum Sprint hinzu?
MrHinsh gibt hier eine großartige Antwort. Erwägen Sie, ein Experiment zu konstruieren, das die Rate und die Kosten der Nacharbeit für Product-Backlog-Elemente in einem Sprint misst, wenn diese zusätzlichen Fehler einfach durch ein Gespräch oder eine andere Methode von Angesicht zu Angesicht behoben werden. Meine Hypothese ist, dass Sie möglicherweise weniger Nacharbeiten sehen und weniger Zeit damit verbringen, fehlerhafte PBIs zu schreiben, und dass Ihr Product Backlog den Wert, den Sie dem Markt zur Verfügung stellen, viel klarer kommuniziert.

Erstens gibt es in Scrum keinen richtigen Weg zum Testen, es gibt nur den Weg, der für das Team funktioniert. Scrum beschreibt keine Praktiken, wenn es ums Testen geht. Wenn Sie der Meinung sind, dass der Weg nicht funktioniert, diskutieren Sie dies während der Retrospektive.

Um Ihre Fragen aus meiner Sicht als Agile-Tester zu beantworten:

  1. Paralleles Testen ist gut, das Erstellen von Fehlerberichten nicht. Als Tester würde ich automatisierte Tests erstellen, um diese neu entdeckten Anforderungen abzudecken, damit ein Entwickler sie implementieren kann. Ich würde die Ergebnisse mit dem Team und dem Product Owner besprechen. Umfangsänderungen sollten in den Rückstand gehen. Fehler in bestehenden Funktionen als Aufgaben auf dem Scrumboard, aber ich würde einen automatisierten Test bevorzugen.

  2. In Scrum beauftragen Sie niemals einen Entwickler, da es sich um ein Pull-System handelt, das Team zieht die noch zu erledigende Arbeit ab, um das Sprint-Ziel zu erfüllen. Jeder Entwickler kann die Fehler beheben, wenn er möchte. Ich würde eine physische Tafel verwenden und ein Post-it mit dem Problem an die Tafel kleben. Das Melden eines Fehlers in einem Fehlertracker scheint Zeitverschwendung zu sein, da ich das Problem lieber zuerst mit dem Team und dem Product Owner bespreche.

  3. Verhindern Sie QA<->DEV-Pingpong, lassen Sie Tester mit den Entwicklern koppeln und stellen Sie sicher, dass die Nacharbeit nach dem ersten Mal perfekt ist. Dies könnte etwas sein, das Sie ausprobieren sollten, wenn dies häufig vorkommt.

Scrum ist ein Teamansatz, rede mit dem Team, löse Probleme mit dem Team. Stoppen Sie das Denken einzelner Entwickler.

Lesen Sie mehr über das Schwärmen:

Ich denke, Ihre dritte Kugel ist untertrieben. Die Qualitätssicherung kann parallel erfolgen, wenn sie mit den Entwicklern zusammenarbeiten.
Kann die QA laufende Aufgaben testen? Wie werden Fehler bei unvollständigen Geschichten gemeldet?
AntwortenHierDatenschutz-Bestimmungen1y, 0v