Lesezeit: 7 Minuten

Der Erfolg eines Projekts hängt von der Fähigkeit eines Entwicklungsteams ab, die Bedürfnisse seines Kunden zu erfüllen. Die Kommunikation zwischen dem Kunden und dem Entwicklungsteam spielt eine wichtige Rolle bei der Bereitstellung einer Lösung, die den Produkt-und Marktanforderungen entspricht., Die Probleme treten auf, wenn Kunden ihre Bedürfnisse zu vage erklären und das Team klare Anforderungen und schließlich das Geschäftsproblem dahinter nicht verstehen kann. Stellen Sie sich vor, Sie bitten Ihr Team, Benutzern die Suche nach einem Produkt in einem Online-Buchladen nach Kategorien zu ermöglichen. Sie erwarten eine übersichtliche Oberfläche mit Kategorielinks, auf die Sie klicken können (z. B. Fantasy, Sachbücher, historisch usw.) Nach zwei Wochen Entwicklung erhalten Sie eine Suchleistenfunktion, in der Benutzer die Kategorie eingeben müssen, an der sie interessiert sind, anstatt zuvor aufgelistete Kategorien zu durchsuchen., Während dies auch funktioniert, war es Ihr ursprüngliches Ziel, alle verfügbaren Kategorien verfügbar zu machen und die Benutzer weiter erkunden zu lassen.

Dies ist, wenn qualitativ hochwertige Software-Dokumentation könnte helfen, das Problem zu vermeiden. User Stories und Akzeptanzkriterien (AC) als Hauptformate zur Dokumentation von Anforderungen. Eine User Story ist eine Beschreibung eines Features in natürlicher Sprache. Es wird normalerweise von Akzeptanzkriterien begleitet.

Akzeptanzkriterien (AC) sind die Bedingungen, die ein Softwareprodukt erfüllen muss, um von einem Benutzer, einem Kunden oder einem anderen System akzeptiert zu werden., Sie sind für jede Benutzerstory eindeutig und definieren das Funktionsverhalten aus der Perspektive des Endbenutzers. Gut geschriebene Akzeptanzkriterien helfen, unerwartete Ergebnisse am Ende einer Entwicklungsphase zu vermeiden und sicherzustellen, dass alle Stakeholder und Benutzer mit dem, was sie erhalten, zufrieden sind.

Akzeptanzkriterien sind die niedrigsten Funktionsanforderungen

Akzeptanzkriterien Hauptzwecke

Die Klärung der Anforderungen des Stakeholders ist ein übergeordnetes Ziel. Um die Zwecke von AC klarer zu machen, lassen Sie uns sie aufschlüsseln.,

Feature-Umfang detalization. AC Definieren Sie die Grenzen von User Stories. Sie bieten genaue Details zur Funktionalität, die dem Team helfen zu verstehen, ob die Story abgeschlossen ist und wie erwartet funktioniert.

Beschreibung negativer Szenarien. Yor AC kann verlangen, dass das System unsichere Passworteingaben erkennt und verhindert, dass ein Benutzer weitergeht. Ungültiges Passwortformat ist ein Beispiel für ein sogenanntes negatives Szenario, wenn ein Benutzer ungültige Eingaben macht oder sich unerwartet verhält. Sie definieren diese Szenarien und erklären, wie das System darauf reagieren muss.

Kommunikation einstellen., Akzeptanzkriterien synchronisieren die Visionen des Kunden und des Entwicklungsteams. Sie stellen sicher, dass jeder ein gemeinsames Verständnis der Anforderungen hat: Entwickler wissen genau, welche Art von Verhalten das Feature demonstrieren muss, während Stakeholder und der Client verstehen, was von dem Feature erwartet wird.

Optimierung der Abnahmetests. AC sind die Grundlage der User Story-Akzeptanzprüfung. Jedes Akzeptanzkriterium muss unabhängig testbar sein und somit ein klares Pass-oder Fail-Szenario aufweisen. Sie können auch verwendet werden, um die Geschichte über automatisierte Tests zu überprüfen.

Feature-Schätzung., Akzeptanzkriterien geben an, was genau vom Team entwickelt werden muss. Sobald das Team genaue Anforderungen hat, kann es User Stories in Aufgaben aufteilen, die korrekt geschätzt werden können.

Akzeptanzkriterien Typen und Strukturen

AC können in verschiedenen Formaten geschrieben werden. Es gibt zwei gebräuchlichste Formate, und die dritte Option besteht darin, ein eigenes Format zu entwickeln:

• szenarioorientiert (Gegeben/Wann/dann)
• regelorientiert (Checkliste)
• benutzerdefinierte Formate

Da das erste und das zweite Format sehr spezifische Strukturen haben, konzentrieren wir uns hauptsächlich auf sie., Sie können jedoch feststellen, dass andere Formate besser zu Ihrem Produkt passen, daher werden wir sie auch kurz ansprechen.

Szenarioorientierte Akzeptanzkriterien

Das szenarioorientierte Format des Schreibens von AC wird als gegebener/Wann/Dann (GWT) – Typ bezeichnet.

• Bei einer Vorbedingung
• Wenn ich eine Aktion durchführe
• Dann erwarte ich ein Ergebnis

Dieser Ansatz wurde von der verhaltensgesteuerten Entwicklung (BDD) geerbt und bietet eine konsistente Struktur, mit der Tester definieren können, wann mit dem Testen eines bestimmten Merkmals begonnen und beendet werden soll., Es reduziert auch den Zeitaufwand für das Schreiben von Testfällen, da das Verhalten des Systems im Voraus beschrieben wird.,

Jedes in diesem Format geschriebene Akzeptanzkriterium enthält die folgenden Anweisungen:

1. Szenario – der Name für das Verhalten, das beschrieben wird
2. Gegeben – der Anfangszustand des Szenarios
3. Wann – spezifische Aktion, die der Benutzer ausführt
4. Dann – das Ergebnis der Aktion in „Wenn“
6. Und – wird verwendet, um eine der drei vorherigen Anweisungen fortzusetzen

Wenn kombiniert, decken diese Anweisungen alle Aktionen ab, die ein Benutzer nimmt, um eine Aufgabe abzuschließen und das Ergebnis zu erleben.

schauen wir uns einige Beispiele an.,

Beispiel 1

User Story: Als Benutzer möchte ich das Passwort für mein Konto wiederherstellen können, damit ich auf mein Konto zugreifen kann, falls ich das Passwort vergessen habe.,

Wenn: Der Benutzer hat die Option Passwort vergessen

ausgewählt Und: Eine gültige E-Mail eingegeben, um einen Link zur Kennwortwiederherstellung zu erhalten

Dann: Das System hat den Link an die eingegebene E-Mail gesendet

Gegeben: Der Benutzer hat den Link über die E-Mail erhalten

Wann: Der Benutzer hat über den in der E-Mail empfangenen Link navigiert

Dann: Das System ermöglicht dem Benutzer, ein neues Passwort festzulegen

Beispiel 2

p>

User story: Als Benutzer möchte ich das Geld von meinem Konto in ATM anfordern können, damit ich das Geld von meinem Konto schnell und an verschiedenen Orten erhalten kann.,deckel

Und: der Spender enthält Bargeld

Wann: der Kunde fordert das Bargeld an

Dann: Stellen Sie sicher, dass das Konto belastet wird

Und: Stellen Sie sicher, dass Bargeld ausgegeben wird

Und: Stellen Sie sicher, dass die Karte zurückgegeben wird

Akzeptanzkriterien 2:

Gegeben: dass das Konto überzogen ist

Und: die Karte ist gültig

Wenn: der Kunde das Bargeld anfordert

/p>

Dann: Stellen Sie sicher, dass die Ablehnungsmeldung angezeigt wird

Und: Stellen Sie sicher, dass kein Bargeld ausgegeben wird

Regelorientiertes Akzeptanzkriterienformat

In einigen Fällen ist es schwierig, Akzeptanzkriterien in die angegebene/Wann/Dann-Struktur einzufügen., Zum Beispiel wäre GWT für die folgenden Fälle kaum nützlich:

• Sie arbeiten mit User Stories, die die Funktionalität auf Systemebene beschreiben, die andere Methoden der Qualitätssicherung benötigt.
• Die Zielgruppe für Akzeptanzkriterien benötigt keine genauen Details der Testszenarien.
• GWT-Szenarien passen nicht zur Beschreibung von Design-und User Experience-Einschränkungen eines Features. Entwickler können eine Reihe kritischer Details verpassen.

Sie können diese Fälle mit dem regelorientierten AC-Format angehen.,

Das regelorientierte Formular beinhaltet, dass es eine Reihe von Regeln gibt, die das Verhalten eines Systems beschreiben. Basierend auf diesen Regeln können Sie bestimmte Szenarien zeichnen.

Normalerweise sehen Kriterien, die mit diesem Formular erstellt wurden, wie eine einfache Aufzählungsliste aus. Schauen wir uns ein Beispiel an.

Beispiel

User Story: Als Benutzer möchte ich ein Suchfeld verwenden, um eine Stadt, einen Namen oder eine Straße einzugeben, damit ich passende Hoteloptionen finden kann.,

Grundlegende Suchoberfläche Akzeptanzkriterien

• Das Suchfeld befindet sich in der oberen Leiste
• Die Suche beginnt, sobald der Benutzer auf „Suchen“klickt
• Das Feld enthält einen Platzhalter mit grauem Text:“ Wohin gehst du?“
• Der Platzhalter verschwindet, sobald der Benutzer mit der Eingabe beginnt
• Die Suche wird durchgeführt, wenn ein Benutzer in eine Stadt, einen Hotelnamen, eine Straße oder alle kombinierten
• Die Suche erfolgt in Englisch, Französisch, Deutsch und Ukrainisch
• Der Benutzer kann nicht mehr als 200 Symbole eingeben
• Die Suche unterstützt keine speziellen Symbole (Zeichen)., Wenn der Benutzer ein spezielles Symbol eingegeben hat, zeigen Sie die Warnmeldung an: „Sucheingabe kann keine speziellen Symbole enthalten.“

Andere Formate

Die meisten User Stories können mit zwei oben genannten Formaten abgedeckt werden. Sie können jedoch Ihre eigenen Akzeptanzkriterien erfinden, da sie ihren Zwecken dienen, klar in einfachem Englisch verfasst sind und nicht falsch interpretiert werden können. Einige Teams verwenden sogar Klartext.,

Manchmal können Ihre Kriterien als Beispiel für das Systemverhalten angegeben werden:

Ein einfacher Satz von AC für sichere Passwörter von Mark Levison für agilepainpainrelief.com

Dieser Ansatz bietet klare Richtlinien für Kennwortfunktionstests.

Verantwortliche Rollen und wie Akzeptanzkriterien erstellt werden

Einige der Kriterien werden vom Product Owner definiert und geschrieben, wenn er den Product Backlog erstellt. Und die anderen können vom Team während User Stories Diskussionen nach Sprint Planung weiter spezifiziert werden., Es gibt keine strengen Empfehlungen zur Auswahl der Person, die für das Schreiben der Kriterien verantwortlich ist. Der Kunde kann sie dokumentieren, wenn er über ausreichende technische und Produktdokumentationskenntnisse verfügt. In diesem Fall verhandelt der Kunde die Kriterien mit dem Team, um gegenseitige Missverständnisse zu vermeiden. Andernfalls werden die Kriterien von einem Product Owner, Business Analyst, Requirements Analyst oder Projektmanager erstellt.,

Der Prozess beginnt mit der Priorisierung von User Story und endet mit der Aushandlung von Details mit dem gesamten Team

Hauptherausforderungen und Best Practices beim Schreiben von Akzeptanzkriterien

Akzeptanzkriterien sehen so aus, als wären sie sehr einfach zu schreiben. Trotz ihrer simplen Formate stellt das Schreiben eine Herausforderung für viele Teams dar. Schauen wir uns die Best Practices genauer an, die helfen, häufige Fehler zu vermeiden.

Dokumentieren Sie Kriterien vor der Entwicklung. Akzeptanzkriterien müssen dokumentiert werden, bevor die eigentliche Entwicklung beginnt., Auf diese Weise wird das Team wahrscheinlich alle Kundenbedürfnisse im Voraus erfassen. Am Anfang reicht es aus, die Kriterien für eine kleine Anzahl von User Stories festzulegen, um die Backlogs für zwei Sprints zu füllen (wenn Sie Scrum oder eine ähnliche Methode üben). Sie müssen von beiden Parteien vereinbart werden. Anschließend werden die dokumentierten Akzeptanzkriterien von Entwicklern zur Planung des technischen Prozesses verwendet.

Machen Sie AC nicht zu eng. Akzeptanzkriterien können viel zu spezifisch und wenig bis gar keine Manövrieroptionen für Entwickler sein. Um dies zu vermeiden, denken Sie daran, dass AC die Absicht vermitteln muss, aber keine endgültige Lösung., Darüber hinaus können enge AC von mehreren Benutzerverhalten beraubt sein, die nicht abgedeckt sind.

Halten Sie Ihre Kriterien erreichbar. Dieser Punkt schneidet sich eng mit dem vorherigen. Effektive Akzeptanzkriterien definieren das angemessene Minimum an Funktionalität, das Sie bereitstellen können. Wenn Sie jedoch der Beschreibung aller kleinen Details erliegen, besteht die Gefahr, dass Ihr Team mit Hunderten von kleinen Aufgaben stecken bleibt.

Halten AC messbar und nicht zu breit. Breite Akzeptanzkriterien machen eine User Story vage., Effektive Akzeptanzkriterien müssen den Umfang der Arbeit umreißen, damit die Entwickler ihren Aufwand richtig planen und abschätzen können.

Vermeiden Sie technische details. Wie bereits erwähnt, müssen Akzeptanzkriterien in einfachem Englisch verfasst werden. Dies macht sie für alle klar und leicht verständlich: Ihre Stakeholder oder Manager haben möglicherweise keinen technischen Hintergrund.

Konsens erreichen. Das gleiche Problem kann von einem Team und Stakeholdern unterschiedlich gelöst werden, abhängig von ihren Aussichtspunkten. Stellen Sie sicher, dass Sie Ihre AC den Stakeholdern mitgeteilt und eine gegenseitige Vereinbarung getroffen haben., Gleiches gilt für Teammitglieder. Jeder muss den AC überprüfen und bestätigen, dass er jede Zeile versteht und ihr zustimmt.

Schreiben testable AC. Auf diese Weise können Tester überprüfen, ob alle Anforderungen erfüllt wurden. Andernfalls werden Entwickler nicht verstehen, ob die User Story abgeschlossen ist.

Letztes Wort

Vernachlässigen Sie nicht die Akzeptanzkriterien, da sie – einfach und zugänglich – mehrere Probleme gleichzeitig lösen., Sie dokumentieren die Kundenerwartungen, bieten eine Endbenutzerperspektive, klären Anforderungen und verhindern Mehrdeutigkeiten und helfen schließlich bei der Qualitätssicherung, zu überprüfen, ob die Entwicklungsziele erreicht wurden. Unabhängig davon, ob Sie agile Methoden verwenden oder nicht, stellen Sie sicher, dass Sie das beste Format auswählen oder mit Ihren eigenen experimentieren. Verschiedene Arten von User Stories und andere Funktionen erfordern möglicherweise andere als das Lesen und Testen der neuen, die für Sie arbeiten, ist eine gute Praxis.