Was ist User Story und Akzeptanzkriterien (Beispiele)

Ein perfekter Leitfaden für User Story Akzeptanzkriterien mit realen Szenarien:

In der Softwareentwicklungsbranche definiert das Wort „Anforderung“, was unser Ziel ist, was die Kunden genau brauchen und was unser Unternehmen dazu bringt, sein Geschäft zu steigern.

Sei es ein Produktunternehmen, das Softwareprodukte herstellt, oder ein Dienstleistungsunternehmen, das Dienstleistungen in verschiedenen Softwarefeldern anbietet, die Hauptbasis für alle ist die Anforderung und der Erfolg wird dadurch definiert, wie gut die Anforderungen erfüllt werden.,

Der Begriff „Anforderung“ hat in verschiedenen Projektmethoden unterschiedliche Namen.

In Waterfall wird es als „Anforderungs – /Spezifikationsdokument“ bezeichnet, in Agile oder SCRUM als „Epic“, „User Story“.

Unter Wasserfallmodell sind die Anforderungsdokumente riesige Dokumente von 200 oder mehr Seiten, da das gesamte Produkt in einer Phase implementiert wird. Dies ist jedoch bei Agile/SCRUM nicht der Fall, da bei diesen Methoden die Anforderungen an kleine Funktionalitäten oder Funktionen gestellt werden, wenn das Produkt Schritt für Schritt vorbereitet wird.,

In diesem Artikel habe ich mein Bestes gegeben, um all meine 4-jährigen Erfahrungen mit der Arbeit mit User Stories und den damit verbundenen Akzeptanzkriterien sowie einfache und einfache reale Szenarien für Ihr besseres Verständnis zu teilen.

Lassen Sie uns zuerst die Grundlagen erneut besuchen.

Was ist eine User Story?

Eine User Story ist eine Voraussetzung für jede Funktionalität oder Funktion, die in einer oder zwei Zeilen und maximal bis zu 5 Zeilen niedergeschrieben ist. Eine User Story ist normalerweise die einfachste mögliche Anforderung und besteht aus einer und nur einer Funktionalität (oder einem Feature).,

Das am häufigsten verwendete Standardformat für die Erstellung einer User Story ist unten angegeben:

Als <Benutzerrolle/Kunde möchte ich < Ziel erreichen> damit ich <Grund des Ziels<486e8bad93 “ > .

Beispiel:

Als WhatsApp-Benutzer möchte ich, dass ein Kamerasymbol im Chat-Schreibfeld Bilder aufnimmt und sendet, damit ich auf meine Bilder klicken und sie gleichzeitig 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 das Feature erfüllen und erfüllen sollte, um vom Product Owner/Stakeholder akzeptiert zu werden.

Dies ist ein sehr wichtiger Teil der Fertigstellung von User Story 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 Aufzählungsliste.

Sein Format ist wie folgt:

„Wenn ich eine Vorbedingung habe, wenn ich eine Aktion durchführe, erwarte ich das Ergebnis“.

Beispiel (w. r.,t to above user story):

• Betrachten wir, dass ich mit einem Freund chatte und in der Lage sein sollte, ein Bild aufzunehmen.
• Wenn ich auf ein Bild klicke, sollte ich dem Bild vor dem Senden eine Beschriftung hinzufügen können.
• Wenn beim Starten meiner Telefonkamera ein Problem auftritt, wird eine Fehlermeldung wie „Kamera konnte nicht gestartet werden“ angezeigt. etc., sollte entsprechend angezeigt werden.

Daher definiert die User Story die Anforderung für jede Funktionalität oder Funktion, während die Akzeptanzkriterien die „Definition von done“ für die User Story oder die Anforderung definieren.,

Als QA ist es sehr wichtig, die User Story und ihre Akzeptanzkriterien zu verstehen, wobei nicht einmal ein einziger Zweifel zu Beginn des Tests bestehen bleibt. Vorwärts gehen Lassen Sie uns verstehen, warum es äußerst wichtig ist, „tief“ in User Stories und Akzeptanzkriterien zu graben.

Tief in User Stories graben

Lassen Sie uns zunächst die Bedeutung einer „eingehenden“ Untersuchung einer grundlegenden und grundlegenden Sache, dh User Stories, verstehen.

Die folgenden Fälle sind meine eigenen realen Erfahrungen.,

Case #1:

Vor 3 Jahren habe ich an einem mobilen Anwendungsprojekt gearbeitet und das Produkt war eine Anwendung, die für die Zusteller entwickelt wurde.

Sie hätten gesehen, wie eine Lieferperson zu Ihrem Lieferort kam. Und sie haben ein Mobiltelefon, auf dem sie Sie bitten, Ihre Unterschrift nach der Lieferung zu geben. Diese Signatur spiegelt sich auf dem Portal der Kurierdienstanbieter wie DTDC, FedEx usw. wider.

Stellen wir uns vor, dass die mobile App gerade gestartet wurde und ihre Portale bereits vorhanden sind.,

Problem: Für einen Sprint hat Ihr Product Owner eine User Story für diese mobile App, die „Als Portaladministrator in der Lage sein sollte, die Signatur anzuzeigen, die der Zusteller zum Zeitpunkt der Lieferung erhalten hat“. Hier wird das Portal (Web App) entsprechend geändert und aktualisiert, um die Signatur widerzuspiegeln.

Als QA 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 das Portal historische Lieferungen anzeigt?“Sollten historische Daten ausgelöscht werden? Sollten wir Abstürze oder Fehler für solche Daten zulassen?

Natürlich überhaupt nicht, das sollte gnädig gehandhabt werden.,

Lösung: Wenn die jeweiligen 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 Aufschrift „Keine Signatur vorhanden“ sollte angezeigt werden.

Dies kann vom Product Owner oder Business Analyst als Miss bezeichnet werden, dies muss jedoch getan 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 habe ich an einer Finanzanwendung für die Altersvorsorge (ohne BA) gearbeitet, bei der es sich um eine globale Anwendung handelte, bei der Finanzberater wie CA es für verschiedene Währungen verwenden konnten, um die Investitionspläne, Ersparnisse usw. zu projizieren., über einen großen Zeitraum zu ihren Kunden.

Problem: Der Product Owner gibt Ihnen eine User Story, dass „ich als Berater den Bericht meines Kunden basierend auf den bereitgestellten finanziellen Details anzeigen möchte“.,

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

a] Die Berichte sollten den täglichen Wechselkurs und nicht den historischen Wechselkurs berücksichtigen, wie im zuletzt angezeigten Bericht und

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

Lösung: Ich habe dieses Anliegen direkt bei unserem Product Owner angesprochen und ihn darauf aufmerksam gemacht, dass beides so schnell wie möglich geschehen muss. Er stimmte mir zu und erstellte 2 verschiedene Geschichten für die kommenden Sprints mit Priorität.,

wegnehmen: Diese gefangen waren, weil wir waren alle sehr wohl bewusst, der Produkte, Ihr design, Ihre Struktur etc. Ein solches Wissen kann nur erreicht werden, indem das Produkt vollständig verstanden wird, die Interoperabilität von Modulen verstanden wird und die User Story gründlich studiert wird, auch wenn es sich um einen 2-Liner handelt.

Machen Sie sich Notizen, um die Dinge einfacher zu machen und diskutieren Sie mit den BA ‚ s und den Entwicklern über ihr Denken.,

Ein eingehender Blick auf Akzeptanzkriterien

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

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

Es gibt eine Option, um den Dateityp zum Herunterladen Ihrer Anweisung auszuwählen. Es gibt eine Option zu wählen, wenn Sie nur die Credits/Debit /both 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 Transaktionen für einen bestimmten Zeitraum anzeigen kann“.,

Mit den folgenden Akzeptanzkriterien:

• In Anbetracht der Tatsache, dass ich mich auf der Seite Historische Anweisung herunterladen befinde, sollte ich den Zeitraum auswählen, für den ich die Anweisung herunterladen möchte.
• Wenn ich bedenke, dass ich mich auf der Seite Historische Kontoauszug herunterladen befinde, sollte ich das Konto auswählen, für das ich die Kontoauszug herunterladen möchte.
• In Anbetracht der Tatsache, dass ich mich auf der Seite „Historische Anweisung herunterladen“ befinde, sollte es mir nicht gestattet sein, die Anweisung für das zukünftige Datum “ Bis “ herunterzuladen.,
• In Anbetracht der Tatsache, dass ich mich auf der Seite Historische Anweisungen herunterladen befinde, sollte es mir nicht gestattet sein, das Datum “ Von “ 10 Jahre später in der Vergangenheit auszuwählen.
• Wenn ich bedenke, dass ich meine Aussage herunterlade, sollte ich die heruntergeladene Datei anzeigen können.
• Wenn ich bedenke, dass ich mich auf der Seite Historische Anweisung herunterladen befinde, sollte ich meine Aussage 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) in der Datei angezeigt werden sollen.
• Die Optionsliste, um auszuwählen, welche Art von Transaktion der Kunde möchte, dh nur belastet oder nur Guthaben oder beides.

Solche Fälle können ab und zu vorkommen, studieren Sie jedoch immer noch gut die einzelnen Akzeptanzkriterien und versuchen Sie, sie in Bezug auf die User Story zu visualisieren. Je mehr Sie sich intensiv mit den Bedingungen und Geschäftsregeln befassen, desto mehr wissen Sie über die Funktion.

Fehler, die in der Anfangsphase gefunden wurden, kosten nichts im Vergleich zu den Kosten in der Testphase.,

Wichtigkeit, Diskrepanzen in User Story/Akzeptanzkriterien zu finden

Es ist immer wichtig, schon vor Beginn der Entwicklung oder des Tests frühzeitig tief in die User Stories und Akzeptanzkriterien einzutauchen.

Weil es beinhaltet:

#1) Zeitverschwendung:

Wenn die Diskrepanzen oder Fehler in den User Story / Akzeptanzkriterien gefunden werden, wenn die Entwicklung läuft oder Tests durchgeführt werden, muss möglicherweise in der verbleibenden Sprintzeit viel Nacharbeit geleistet werden.,

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

Daher wird es für das Team zu einem Albtraum, 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 so früh wie möglich studiert und diskutiert werden.

#2) Verschwendung von Anstrengungen:

Die Entwickler und QA müssen den implementierten Code und die Testfälle erneut besuchen., Aktualisieren, Hinzufügen und Entfernen als pro Anforderung ist keine leichte Aufgabe. Es wird zu schmerzhaft, da es bereits einen Druck gibt, 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.

Schlussfolgerung

Ein tiefes Verständnis von User Story und Akzeptanzkriterien kann nur erreicht werden, wenn man immense Zeit mit dem Studium verbringt.,

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

Die aktive Teilnahme am Pre-Plan-Meeting, das Gespräch mit dem BA und das eigene Studium können Ihnen nur dabei helfen. Je mehr Anstrengungen Sie unternehmen, desto mehr lernen und wachsen Sie.

Sei es die QS oder Entwickler, jeder muss auf der gleichen Seite über die User Stories und ihre Akzeptanzkriterien sein, nur dann können die Erwartungen des Kunden erfolgreich erreicht werden.,

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