Scrum: Sollen Akzeptanzkriterien für User Storys auf Testfälle abgebildet werden?

TL;DR

Die Akzeptanzkriterien sollten Teil der Feature-Story sein und die Grundlage für die Testfälle bilden. Es sollte keine separate Testgeschichte geben, sie könnten eine Teilaufgabe der Geschichte sein!

Lange Antwort

Sollten die Akzeptanzkriterien für eine User Story die Grundlage für die Testfälle beim Testen dieser Funktion bilden?

Natürlich sollten sie sein! Sie definieren, welche Kriterien erfüllt sein müssen, damit die Story ihren Usecase erfüllt. Diese Kriterien sollten getestet werden, um sicherzustellen, dass die Geschichte fertig ist. Dies bedeutet, dass Sie verschiedene Arten von Tests (Unit-Tests, Regressionstests ...) implementieren müssen.

Oder sollte es eine separate Story zum Testen geben, deren Akzeptanzkriterium darin besteht, dass das zu testende Feature den relevanten Abschnitt der Funktionsspezifikation besteht?

Der Scrum-Leitfaden macht das ganz klar, wenn er den Begriff „Done“ definiert: „Jedes Inkrement wird ... gründlich getestet, um sicherzustellen, dass alle Inkremente zusammen funktionieren.“ Das bedeutet, dass die Geschichte abgeschlossen ist, wenn alle Aufgaben erledigt sind - einschließlich der Tests. Also keine extra Geschichte oder gar ein extra Team dafür!

Beispiel

Was könnten die Akzeptanzkriterien sein und in welcher Beziehung stehen diese zu den Tests?

Ich habe Ihr Story-Beispiel modifiziert, indem ich Implementierungsdetails entfernt habe, es sollte nur der Kundenbedarf beschrieben werden. Der „Klick-Teil“ wurde zu den Akzeptanzkriterien verschoben.

Geschichte

Als Benutzer möchte ich in der Lage sein, eine Karte mit der markierten gemeldeten Adresse anzuzeigen, damit ich visualisieren kann, wo das Ereignis auftritt.

Akzeptanzkriterien

• Es gibt einen Button 'Karte anzeigen' um die Kartenansicht zu öffnen (Google Maps)
• Die gemeldete Adresse ist auf der Karte markiert
• Wenn keine Adresse markiert ist, ist die Schaltfläche deaktiviert
• ...

Diese Kriterien sollten jetzt getestet werden, versuchen Sie, über Sonnenszenarien und häufige Fehler nachzudenken - vergessen Sie nicht die Grenzfälle.

Ich kenne Ihre Anwendung nicht, also versuche ich, sie allgemein zu halten. Sie haben eine Art Benutzertests, bei denen sich ein Teamkollege durch die App klickt und auf die Schaltfläche "Karte anzeigen" klickt (markierte Karte wird angezeigt). Eine andere Sache wäre sicherzustellen, dass die Google Maps-API Ihr Adressformat verstehen kann (möglicherweise automatisiert) oder Sie testen, was passiert, wenn Google Maps nicht verfügbar ist. Außerdem haben Sie eine Art Unit-Tests, die testen können, was passiert, wenn das Adressfeld leer ist.

Was ist dann der Unterschied zu User Stories?

Statt „Akzeptanzkriterien“ könnten Sie auch folgende User Stories definieren:

Als Benutzer möchte ich eine Schaltfläche „Karte anzeigen“, damit ich die Kartenansicht (Google Maps) öffnen kann. Als Benutzer erwarte ich, dass die gemeldete Adresse auf der Karte markiert wird. Als Benutzer möchte ich, dass die Schaltfläche „Karte anzeigen“ deaktiviert ist Es ist keine Adresse angegeben

Vereinfacht die Planung, Priorisierung und Nachverfolgung der Implementierung.

Die Benutzergeschichte sollte geschrieben werden, indem sie sich auf den Geschäftswert und nicht auf Funktionalitäten konzentriert.

Als Benutzer benötige ich beispielsweise die Option, den Veranstaltungsort auf der Google-Karte anzuzeigen, damit ich den Ort visualisieren kann.

Sie können bestimmte Funktionen schreiben, die der Benutzer als akzeptanzkritisch erwartet.

Die Karte sollte zB angezeigt/aufgeklappt werden, sobald der Benutzer auf die Schaltfläche „Karte anzeigen“ klickt.

Das Testteam kann beim Testen der Story individuelle Akzeptanzkriterien testen.

Beispielsweise kann der Tester auf die Schaltfläche klicken, um zu überprüfen, ob die Karte Eigentum anzeigt.