Was sind User Story- und Akzeptanzkriterien (Beispiele)

Beispiel:

Als WhatsApp-Benutzer möchte ich, dass ein Kamerasymbol im Chat-Schreibfeld Bilder aufzeichnet und sendet, damit ich gleichzeitig auf meine Bilder klicken und sie mit allen meinen Freunden teilen kann.

Was ist ein Akzeptanzkriterium?

Ein Akzeptanzkriterium ist eine Reihe akzeptierter Bedingungen oder Geschäftsregeln, die die Funktionalität oder Funktion erfüllen und erfüllen sollte, um vom Product Owner / Stakeholder akzeptiert zu werden.

Dies ist ein sehr wichtiger Teil der Fertigstellung von User Storys und sollte vom Product Owner und Business Analyst sehr sorgfältig untersucht werden, da das Fehlen eines einzelnen Kriteriums viel kosten kann. Dies ist eine einfache nummerierte oder mit Aufzählungszeichen versehene Liste.

Das Format ist wie folgt:

'' Unter bestimmten Voraussetzungen, wenn ich etwas unternehme, erwarte ich das Ergebnis ”.

Vanilla World of Warcraft privater Server

Beispiel (mit der obigen User Story):

• Nehmen wir an, ich chatte mit einem Freund und sollte in der Lage sein, ein Bild aufzunehmen.
• Wenn ich auf ein Bild klicke, sollte es mir möglich sein, dem Bild eine Beschriftung hinzuzufügen, bevor ich es sende.
• Wenn beim Starten meiner Telefonkamera ein Problem auftritt, wird eine Fehlermeldung wie 'Kamera konnte nicht gestartet werden' angezeigt. usw. sollten entsprechend angezeigt werden.

Daher definiert die User Story die Anforderung für Funktionen oder Features, während die Akzeptanzkriterien die 'Definition von erledigt' für die User Story oder die Anforderung definieren.

Als QS ist es sehr wichtig, die User Story und ihre Akzeptanzkriterien gründlich zu verstehen, ohne dass zu Beginn des Tests ein einziger Zweifel besteht. Lassen Sie uns in Zukunft verstehen, warum es äußerst wichtig ist, sich eingehend mit User Stories und Akzeptanzkriterien zu befassen.

Tief in User Stories eintauchen

Lassen Sie uns zunächst die Bedeutung einer eingehenden Untersuchung einer grundlegenden und grundlegenden Sache verstehen, d. H. Benutzergeschichten.

Die folgenden Fälle sind meine eigenen realen Erfahrungen.

Fall 1:

Vor 3 Jahren arbeitete ich an einem Projekt für mobile Anwendungen und das Produkt war eine Anwendung, die für Zusteller entwickelt wurde.

Sie hätten gesehen, wie ein Zusteller zur Lieferung zu Ihnen kam. Und sie haben ein Mobiltelefon, auf dem sie Sie bitten, nach der Lieferung Ihre Unterschrift zu geben. Diese Unterschrift spiegelt sich auf dem Portal der Kurierdienstleister wie DTDC, FedEx usw. wider.

Stellen wir uns vor, die mobile App wird gerade gestartet und ihre Portale sind bereits vorhanden und verfügbar.

Problem:: Für einen Sprint hat Ihr Product Owner eine User Story für diese mobile App, die 'Als Portaladministrator sollte ich in der Lage sein, die Unterschrift des Zustellers zum Zeitpunkt der Zustellung anzuzeigen.' . Hier wird das Portal (Web-App) entsprechend geändert und aktualisiert, um die Signatur widerzuspiegeln.

Als Qualitätssicherung müssen Sie überprüfen, ob die in der mobilen App erfasste Signatur wie erwartet im Portal angezeigt wird.

Wenn Sie sich diese User Story ansehen, sieht es einfach aus, aber es gibt hier eine versteckte Anforderung: 'Für historische Lieferungen gab es keine Signaturreflexionsfunktion. Was sollte also passieren, wenn die Portal-Mitarbeiter historische Lieferungen anzeigen?' Sollten historische Daten gelöscht werden? Sollten wir Abstürze oder Fehler für solche Daten zulassen?

Natürlich überhaupt nicht, dies sollte freundlich behandelt werden.

Lösung: Wenn die entsprechenden DB-Tabellen aktualisiert werden, um eine neue Spalte für den Signaturspeicherort hinzuzufügen, sollten die alten Daten einen NULL- oder 0-Wert haben, der überprüft werden sollte, und eine Meldung mit der Angabe 'Keine Signatur vorhanden' sollte angezeigt werden.

Dies kann vom Product Owner oder Business Analyst als Miss bezeichnet werden, muss jedoch durchgeführt werden. Eine Funktion erfolgreich zu implementieren, aber etwas damit zu brechen, ist für die Kunden nicht wünschenswert. Dies muss zusammen mit derselben User Story und im selben Sprint erfolgen.

Fall 2

Vor 6 Jahren arbeitete ich an einer Finanzanwendung für die Altersvorsorge (ohne BA), einer globalen Anwendung, bei der Finanzleute wie CA, Finanzberater sie für verschiedene Währungen verwenden konnten, um die Investitionspläne, Einsparungen usw. über einen Zeitraum zu projizieren große Zeit für ihre Kunden.

Problem:: Der Product Owner gibt Ihnen eine User Story, die 'Als Berater möchte ich den Bericht meines Kunden anhand der bereitgestellten finanziellen Details anzeigen.'

Hier gab es 2 versteckte Anforderungen und ich würde es als unvollständige Geschichte bezeichnen, weil:

zu) In den Berichten sollte der tägliche Währungsumrechnungskurs berücksichtigt werden und nicht der historische wie im zuletzt angezeigten Bericht und

b) Wenn die Währung nach Angabe der Finanzdaten des Kunden geändert wird, sollten die Berichte in der geänderten Währung angezeigt werden.

Lösung:: Ich habe dieses Problem direkt bei unserem Product Owner angesprochen und ihn darauf aufmerksam gemacht, dass beide so schnell wie möglich erledigt werden müssen. Er stimmte mir zu und erstellte 2 verschiedene Geschichten für die bevorstehenden Sprints mit Priorität.

Wegbringen:: Diese wurden gefangen, weil wir uns alle der Produkte, ihres Designs, ihrer Struktur usw. sehr gut bewusst waren. Dieses Wissen kann nur erreicht werden, wenn man das Produkt vollständig versteht, die Interoperabilität von Modulen versteht und die User Story gründlich studiert, auch wenn dies der Fall ist ein 2 Liner.

Machen Sie sich Notizen, um die Sache zu vereinfachen, und diskutieren Sie mit den BAs und den Entwicklern über ihr Denken.

Detaillierte Betrachtung der Akzeptanzkriterien

Das umfassende Verständnis der Akzeptanzkriterien und aller anderen Bedingungen und Regeln ist noch wichtiger als das Verstehen einer User Story. Denn wenn eine Anforderung unvollständig oder vage ist, kann sie im nächsten Sprint aufgenommen werden. Wenn jedoch ein Akzeptanzkriterium verfehlt wird, kann die User Story selbst nicht veröffentlicht werden.

Ich denke, wir alle hätten irgendwann Net Banking genutzt und die meisten von uns nutzen es jeden Tag und ich lade meine historischen Aussagen oft herunter. Wenn Sie es genau beobachten, stehen Ihnen bestimmte Optionen zum Herunterladen zur Verfügung.

Sie können den Dateityp zum Herunterladen Ihrer Anweisung auswählen. Sie können wählen, ob Sie nur die Credits / Debit / beide herunterladen möchten.

Stellen Sie sich nun vor, der Product Owner gibt Ihnen diese User Story: 'Als Kunde möchte ich meinen Kontoauszug herunterladen, damit ich alle meine für einen bestimmten Zeitraum getätigten Transaktionen anzeigen kann.'

Mit folgenden Akzeptanzkriterien:

• Da ich mich auf der Seite 'Historische Erklärung herunterladen' befinde, sollte ich den Zeitraum auswählen, für den ich die Erklärung herunterladen möchte.
• Da ich mich auf der Seite 'Historische Erklärung herunterladen' befinde, sollte ich das Konto auswählen, für das ich die Erklärung herunterladen möchte.
• In Anbetracht der Tatsache, dass ich mich auf der Seite 'Historische Erklärung herunterladen' befinde, sollte es mir nicht gestattet sein, die Erklärung für ein zukünftiges 'Bis' -Datum herunterzuladen.
• In Anbetracht der Tatsache, dass ich mich auf der Seite 'Historische Erklärung herunterladen' befinde, sollte es mir nicht gestattet sein, das Datum 'Ab' 10 Jahre nach der Vergangenheit auszuwählen.
• Wenn ich meine Erklärung herunterlade, sollte ich die heruntergeladene Datei anzeigen können.
• In Anbetracht der Tatsache, dass ich mich auf der Seite 'Historische Erklärung herunterladen' befinde, sollte ich meine Erklärung in den Formaten doc, excel und pdf herunterladen können.

Wenn Sie diese Annahme durchlaufen, fehlen hier drei Dinge:

• Name und Format des Dateinamens, der heruntergeladen wird.
• Welche Informationen (Spaltennamen) sollen in der Datei angezeigt werden?
• In der Optionsliste können Sie auswählen, welche Art von Transaktion der Kunde wünscht, d. H. Nur Belastungen oder nur Gutschriften oder beides.

Solche Fälle können gelegentlich auftreten, studieren jedoch immer noch die einzelnen Akzeptanzkriterien und versuchen, sie anhand der User Story zu visualisieren. Je mehr Sie sich eingehend mit den Bedingungen und Geschäftsregeln befassen, desto besser wird Ihr Wissen über die Funktion.

In der Anfangsphase gefundene Fehler kosten nichts im Vergleich zu den Kosten in der Testphase.

Wichtigkeit, Diskrepanzen in User Story / Akzeptanzkriterien zu finden

Es ist immer wichtig, frühzeitig in die User Stories und Akzeptanzkriterien einzutauchen, noch bevor die Entwicklung oder das Testen beginnt.

Weil es beinhaltet:

# 1) Zeitverschwendung:

Wenn die Unstimmigkeiten oder Fehler in den User Story- / Akzeptanzkriterien während der Entwicklung oder beim Testen festgestellt werden, müssen in der verbleibenden Sprintzeit möglicherweise viele Nacharbeiten durchgeführt werden.

Es kommt nicht vor, dass der Product Owner die User Story auf den kommenden Sprint verschiebt, selbst wenn er einige Dinge übersehen hat. 95% der Chancen stehen gut, dass sie das Team bitten, die erforderliche Implementierung durchzuführen und sie im selben Sprint freizugeben.

Daher wird es zu einem Albtraum für das Team, da es zusätzliche Zeit verbringen, am Wochenende kommen oder spät in der Nacht arbeiten muss. Dies kann vermieden werden, indem die User Story- / Akzeptanzkriterien zum frühestmöglichen Zeitpunkt untersucht und diskutiert werden.

# 2) Verschwendung von Anstrengungen:

Die Entwickler und die Qualitätssicherung müssen den implementierten Code und die Testfälle erneut überprüfen. Das Aktualisieren, Hinzufügen und Entfernen nach Bedarf ist keine leichte Aufgabe. Es wird zu schmerzhaft, da bereits der Druck besteht, pünktlich zu liefern.

In einer solchen Situation besteht die Möglichkeit von Fehlern in der Entwicklungs- oder Testphase. Wenn Sie auf eine solche Situation stoßen, wählen Sie 'DevQA Pairing'. Als Sahnehäubchen erhalten Sie möglicherweise keine Entschädigung für die zusätzliche Arbeit.

Fazit

Ein tiefes Verständnis der User Story und der Akzeptanzkriterien kann nur erreicht werden, wenn man viel Zeit damit verbringt, sie zu studieren.

Es gibt kein spezielles Tool oder einen speziellen Kurs auf dem Markt, um dies für Sie zu tun, da es um logisches Denken, Erfahrung und Wissen über das Produkt geht.

Eine aktive Teilnahme am Pre-Plan-Meeting, ein Gespräch mit dem BA und ein eigenständiges Studium können Ihnen nur dabei helfen, dies zu erreichen. Je mehr Anstrengungen Sie unternehmen, desto mehr lernen Sie und wachsen.

Ob QA oder Entwickler, jeder muss über die User Stories und ihre Akzeptanzkriterien auf der gleichen Seite sein, nur dann können die Erwartungen des Kunden erfolgreich erfüllt werden.

Haben Sie uns etwas Neues über Ihre Erfahrungen mit User Stories mitzuteilen? Bitte drücken Sie Ihre Gedanken unten aus!

Literatur-Empfehlungen

• MongoDB Benutzer erstellen und Rollen mit Beispielen zuweisen
• Beispielvorlage für einen Abnahmetestbericht mit Beispielen
• Benutzerauthentifizierung in MongoDB
• JMeter-Datenparametrierung mit benutzerdefinierten Variablen
• Unix-Berechtigungen: Dateiberechtigungen unter Unix mit Beispielen
• Was ist Akzeptanztest (eine vollständige Anleitung)
• Was ist User Acceptance Testing (UAT): Ein vollständiger Leitfaden
• Python DateTime Tutorial mit Beispielen