ScopeMaster-zehn-Tests-für-großartige-User-Stories

Beginnen Sie mit dem Testen der User Story

Bei den meisten Softwareaktivitäten sind die User Stories eine knappe Erinnerung an die Gespräche zwischen Product Owner, Entwickler und Tester. Obwohl User Stories sehr kurz sind, wird die Form häufig falsch verwendet, was zu Unklarheiten, unnötigen Diskussionen und Nacharbeiten führt. In diesem Artikel legen wir fest, wie Sie User Storys testen, damit Sie sicherstellen können, dass Ihre User Stories von hoher Qualität sind und die Nacharbeit reduziert und die Zeitpläne verkürzt werden.

Ich habe online eine ausführliche Debatte darüber geführt, ob es sinnvoll ist, überhaupt über die Qualität der User Story nachzudenken. Wenn Sie akzeptieren, dass klare User Storys für ein Projekt hilfreich sind, dann sollte das Konzept des User Story Testings für Sie sinnvoll sein.

Lernen Sie diese zehn Tests zum Schreiben großartiger User Stories.

1. Klar

Ihre User Stories müssen es sein klar und eindeutig. Produktbesitzer, Entwickler und Tester sollten alle ein gemeinsames Verständnis davon haben, was mit dem Text der Geschichte geliefert werden soll. Gehen Sie beim Schreiben Ihrer Geschichten davon aus, dass sie möglicherweise falsch interpretiert werden können. Stellen Sie außerdem sicher, dass Ihre Storys alle erforderlichen Funktionen enthalten (mit Ausnahme der Navigation).

Tipp: Konzentrieren Sie sich auf die funktionale Absicht der User Story, z. B. „Als registrierter_Benutzer kann ich mein Profil aktualisieren“

Hintergrund

Wird wahrscheinlich missverstanden

Wir haben über 100.000 User Stories analysiert und festgestellt, dass die durchschnittliche Story-Länge 12 Wörter beträgt. Mathematisch gesehen gibt es über 80 Milliarden Permutationen von 12 Wörtern. Das bedeutet, dass es für Leser nahezu unbegrenzte Möglichkeiten gibt, User Stories falsch zu interpretieren.

Schlechte User Stories führen zu übermäßiger Nacharbeit (±125 Mal)

Außerdem haben wir geschätzt, dass jedes Wort einer User Story im Durchschnitt zu 125 Codierungsbegriffen führt. Das bedeutet, dass ein Fehler (der zu einem Missverständnis führen kann) zu erheblicher Nacharbeit führt, sobald mit der Codierung begonnen wird.

Durch die zunehmende Fernarbeit sind wir stärker auf das geschriebene Wort angewiesen. Es kommt darauf an, die richtigen Worte zu finden.

Automatisierte Klarheitsprüfung

Die meisten User Stories sind anfällig für Fehlinterpretationen. ScopeMaster® führt eine detaillierte Sprachanalyse jedes Wortes innerhalb der User Story durch, um die funktionale(n) Bedeutung(en) zu erkennen. Die Analyse-Engine wurde speziell für die eindeutige Unterscheidung von Software-User-Storys entwickelt (erkennt Subjekt-Verb-Objekt-Muster im Text). Dies ist die Grundlage dafür, wie die Analyse-Engine „das ultimative Shift-Left-Testing“ durchführt.

Die Analyse-Engine führt außerdem Hunderte von linguistischen Prüfungen auf mehrdeutige Phraseologie und Begriffe durch, die zu einer Fehlinterpretation der User Story führen könnten. Diese Tests basieren auf den Lehren einiger der weltweit führenden Anforderungsexperten. (Es ist eher so, als würden alle Ihre User Stories von Experten überprüft).

2. Prägnant

Halten Sie sie kurz. Geschichten müssen nicht lang sein, um die wesentliche funktionale Bedeutung zu vermitteln. Ein oder mehrere kurze Sätze können ausreichend sein. Denken Sie daran, dass die Akzeptanzkriterien eine Ergänzung zur Geschichte sind.

Tipp: Vermeiden Sie Beschreibungen zu Navigation, Implementierungsdetails, Akzeptanzkriterien und Objektattributen.

Tipp: Implementierungsdetails vermeiden.

Tipp: Trennen Sie die Akzeptanzkriterien von der Kern-User-Story.

Automatisierte Prägnanzprüfung

ScopeMaster® führt eine detaillierte Analyse der Wörter jeder User Story durch und hebt den übermäßigen Gebrauch unnötiger Wörter hervor.

Statische Anforderungstests

ScopeMaster® führt Hunderte von Tests für jede User Story durch. Es ist wie SonarQube, aber für User Stories.

3. Benutzerorientiert

Eine Geschichte sollte aus der Perspektive des Benutzers geschrieben werden. Die typische agile Empfehlung ist das Format:

Als ein Benutzertyp Ich möchte etwas ausführen so dass Grund

In einigen Fällen ist die Benutzertyp Möglicherweise handelt es sich um eine andere Software oder möglicherweise sogar um ein Gerät, das mit der Software interagiert, beispielsweise um einen Sensor.

Tipp: Schreiben Sie Ihre Geschichten niemals aus der Perspektive des Entwicklers.

Tipp: Vermeiden Sie den allgemeinen Begriff Benutzer, verwenden Sie stattdessen umfassende, konsistente Bezeichnungen für Benutzertyp oder Rolle, z. B registrierter Nutzer oder unauthenticated_visitor

Automatisierte Benutzererkennungstests

Der ScopeMaster®-Analysator erkennt potenzielle Benutzer in jeder Story. ScopeMaster hebt Instanzen von Geschichten hervor, die keinen Benutzer haben. Optional können Sie dem Analysator mitteilen, welches das „Benutzer“-Wort in Ihrer Geschichte ist.

4. Testbar

Eine Geschichte kann testbar sein, wenn sie klare Aussagen zur Funktionalität enthält. Verwenden Sie Ausdrücke, die auf die Bewegung, Speicherung und den Abruf von Daten schließen lassen. Beispiele für überprüfbare Geschichten sind Phrasen wie: "Profil aktualisieren", „Verkaufsbericht anzeigen“, "E-Mail senden". Wenn Sie Ihre Geschichten auf diese Weise schreiben, stellen Sie sicher, dass die Kernfunktionsabsicht klar ist. Dies bildet die Grundlage, auf der Testszenarien generiert werden können. Die vollständige Testsuite hängt normalerweise von zusätzlichen detaillierten Akzeptanzkriterien ab.

Tipp: Die detaillierten Akzeptanzkriterien ergänzen die Kern-User Story. Betten Sie Akzeptanzkriterien nicht in den Text der User Story ein.

Automatisierte Testgenerierung

Da die ScopeMaster®-Engine die funktionale Absicht Ihrer User Story „kennt“, schlägt sie Testszenarien und wesentliche Testfälle vor, die als Grundlage für Funktionstests verwendet werden können. Die von ScopeMaster generierten Tests sind 100% auf die Funktionalität der User Story abgestimmt. Sie umfassen sowohl positive als auch negative Tests. Sie können als die wesentlichen Mindesttests angesehen werden, die durchgeführt werden müssen. Dies ist eine große Zeitersparnis für Testprofis.

5. Messbar

Ich beziehe mich hier auf die Messbarkeit der Größe, konkret anhand der KOSMISCHER Funktionspunkt (CFP) als Grundlage für die Dimensionierung. Es handelt sich um einen ausgereiften ISO-Standard der zweiten Generation, der für alle Arten von Softwarearbeiten geeignet ist. User Stories können nur dann gemessen werden, wenn sie klare Ausdrücke aller Datenbewegungen enthalten, die benötigt und gemessen werden. Messbarkeit hilft sowohl bei der Planung als auch bei der Qualitätssicherung erheblich. Die funktionale Größe ist nicht das einzige messbare Merkmal einer User Story, sie ist jedoch eines der wichtigsten (weil sie sehr eng mit dem Aufwand für die Erstellung zusammenhängt).

Tipp: Wenn Sie die Größe nicht messen, wird Ihre Software-Arbeit unsicherer.

Tipp: Erfahren Sie in diesem Leitfaden mehr über die COSMIC-Größenbestimmungsmethode.

Hintergrund

Die grundlegende Größeneinheit ist die KOSMISCHER Funktionspunkt Dies ist ein ISO-Standard für die Größe. Beginnen Sie Ihre Lernreise mit diesem aktualisierten, Leitfaden für Messsoftware.

Eine frühe CFP-Schätzung ist sehr nützlich, da die Schätzung näher zu einer genaueren Messung führt, wenn die Einzelheiten der Anforderung bekannt werden.

Universell einsetzbar

Für diejenigen, die sich davor sträuben, die (funktionale) Größe der Anforderungen abzuschätzen oder zu messen, sollten Sie Folgendes bedenken. Die Mindestgröße einer User Story beträgt 2-3 CFP. Die typischen Kosten für die Entwicklung eines CFP betragen $200 – $2000. Die für die Schätzung der Größe benötigte Zeit beträgt manuell etwa 10 Minuten pro CFP oder 2 Minuten mithilfe der Automatisierung. Die Kenntnis der Größe ist unglaublich wertvoll, um zu bestimmen, wie viel das Projekt kosten wird, wie lange es dauern wird und mehr. Sowohl die Aktivität „Kenntnis der Größe“ als auch „Durchführung der Größenbestimmung“ verringert die Unsicherheit und verbessert die Qualität.

Automatisierte Größenschätzung

ScopeMaster wurde ursprünglich mit dem primären Ziel entwickelt, die Funktionsgröße (COSMIC- und IFPUG-Funktionspunkte) anhand der Softwareanforderungen zu bestimmen. Es wurde bestätigt, dass die Größenschätzungen von ScopeMaster typischerweise innerhalb von 15% einer manuell ermittelten Größe liegen. Dies reduziert nicht nur den Arbeitsaufwand für die Dimensionierung, sondern hilft auch dabei, die formelle technische Dimensionierung für diejenigen einzuführen, die derzeit nicht wissen, dass solche wertvollen Techniken existieren.

6. Konsequent

Verwenden Sie für beide einheitliche Wörter Benutzertypen Und Objekttypen über eine Reihe von User Stories hinweg. Durch eine einheitliche Benennung werden Verwirrung, Fehler, Nacharbeit und Verschwendung reduziert. Komplexe Systeme und umgangssprachliche Umgebungen neigen dazu, dass Teammitglieder demselben Benutzer oder demselben Objekt unterschiedliche Begriffe geben.

Automatisierte Konsistenzprüfungen

Nachdem der einzelne Text jeder Story analysiert wurde, stellt die ScopeMaster-Engine Querverweise auf alle User Stories innerhalb eines Sets (oder Backlogs) her. Es identifiziert jedes Vorkommen von Objekttypen und stellt sie in tabellarischer Form dar, sodass Inkonsistenzen einfach und schnell erkannt werden können.

7. Fertig

Fehlende Anforderungen sind eine der häufigsten Ursachen für das Scheitern von Softwareprojekten. Die meisten Projekte werden größer, wenn sich zusätzlicher Bedarf abzeichnet. Diese Erweiterung des Umfangs führt zu mehr Arbeit, mehr Nacharbeit, verlängerten Zeitplänen, Budgetüberschreitungen und in einigen Fällen zum Scheitern von Wettbewerbsprojekten. Obwohl der agile Ansatz von übermäßiger Vorarbeit abhält, Im Vorfeld ist eine gewisse Scoping-Arbeit unerlässlich. Achten Sie beim Schreiben Ihrer User Stories sorgfältig auf die fehlenden Anforderungen.

Automatisierte Vollständigkeitsprüfung

Die ScopeMaster-Analyse-Engine identifiziert alle Vorkommen eines Objekttyps in einer Reihe von User Stories. Anschließend wird eine CRUD-Analyse durchgeführt. um potenziell fehlende Geschichten zu identifizieren. ScopeMaster schlägt sogar vor, was die fehlende Geschichte sein könnte.

Für Projektmanager ist es äußerst wertvoll, sich bereits zu Beginn seines Lebenszyklus ein umfassendes Verständnis über den gesamten Umfang eines Projekts zu verschaffen.

8. Einzigartig

Alle Anforderungen sollten einzigartig sein. Doppelte Anforderungen sind ein Problem, das bei größeren Projekten tendenziell häufiger auftritt.

Automatisierte Eindeutigkeitsprüfung

Die ScopeMaster-Analyse-Engine identifiziert alle Vorkommen eines Objekttyps (und der damit verbundenen funktionalen Absicht) in einer Reihe von User Stories. Wenn es zwei Storys gibt, die denselben CRUD-Vorgang an einem Objekt ausführen, werden diese hervorgehoben.

9. Wertvoll

Alle User Stories sollten für das „Unternehmen“ wertvoll sein. Es ist angebracht, den Wert und die Bedeutung jeder User Story zu hinterfragen, sodass nur die wichtigste Funktionalität bereitgestellt wird. Wenn eine User Story nicht auf die Bereitstellung eines messbaren Geschäftsergebnisses zurückgeführt werden kann, ist sie möglicherweise nicht wertvoll und sollte möglicherweise aus dem Umfang entfernt werden. Der tatsächliche finanzielle Wert der Geschichte kann schwer zu messen sein, wenn man die funktionale Größe (CFP) als Grundlage für den Wert verwendet (insbesondere für die Messung des Ertragswerts (EVM)).

10. Designfrei

User Stories sollten sich nicht auf die Technologie beziehen, mit der sie bereitgestellt werden. Dieser Detaillierungsgrad kann als Ergänzung zur User Story eingefügt werden, um einen Kontext darüber bereitzustellen, „wie“ die Story bereitgestellt werden soll. Dies eignet sich besonders für nicht funktionale Aspekte, wie die Funktionalität erreicht wird.

Automatisierte Prüfung auf Fachsprache

Die ScopeMaster-Analyse-Engine sucht nach Hunderten von technischen Phrasen und anderer Terminologie, die für User Stories ungeeignet sind.

Empfehlung

Lassen Sie ScopeMaster Ihre User Stories für Sie testen. Importieren Sie einfach und drücken Sie den grünen Knopf. Die intelligente Sprachanalyse bewertet die Qualität und gibt Empfehlungen zur Verbesserung Ihrer User Stories.

Abschluss

Je mehr wir uns in Richtung Remote-Arbeit bewegen, desto stärker wird unsere Abhängigkeit vom geschriebenen Wort bei der Softwareentwicklung. Nehmen Sie sich Zeit, um die richtigen Worte zu finden. Qualitativ hochwertige User Stories sind die Grundlage hochwertiger Software. Sie sollten User Stories testen, bevor Sie mit dem Codieren beginnen, um Zeitverschwendung zu vermeiden.

Jeder dieser 10 Tests stellt ein Qualitätsmerkmal einer guten User Story dar. Sie können dies als Checkliste verwenden, um jede von Ihnen geschriebene User Story abzugleichen. Das Testen von User Stories wird sich erheblich auszahlen, da es die Nacharbeit reduziert, die Ausweitung des Umfangs verringert und die Volatilität des Umfangs verringert. Und wenn Sie es schneller machen möchten, probieren Sie ScopeMaster aus, es übernimmt die schwere Arbeit beim Testen von User Storys.

Agile User Stories

Viele Agilisten nutzen das INVEST-Checkliste Kriterien für User Stories ursprünglich von Bill Wake:

ICHunabhängig
Nverhandelbar
Vwertvoll
Estimulierbar
SEinkaufszentrum
Tstabil

Seien Sie vorsichtig bei der Verwendung von INVEST

Der ursprüngliche Autor weist darauf hin, dass INVEST eine unvollständige Teilmenge von Attributen ist.
Es wird nicht berücksichtigt, dass Benutzergeschichten voneinander abhängig sein können.
Es erfordert, dass Geschichten benutzerorientiert sind.
Es besteht nicht darauf, dass Geschichten eindeutig sind.
Es erkennt nicht die Gefahren an, die mit einem unvollständigen Verständnis des Umfangs einhergehen.
Es fördert keine disziplinierte Analyse (konsistente Benennung, Benutzerorientierung, Prägnanz)
Es ist nicht erforderlich, dass Geschichten messbar sind (obwohl es sich auf „Schätzbar“ bezieht, ist dies ein sehr lockeres Kriterium).

In der ursprünglichen Gründung von INVEST wird auch erwähnt, dass Aufgaben unterschiedlich behandelt werden sollten, und es wird das Akronym SMART verwendet:

Spezifisch
Messbar
Erreichbar
Realistisch
Zeit gebunden

Ich habe SMART-Checks immer als effektiv und für Aufgaben geeignet empfunden, aber nicht für User Stories.

Warum sollten wir bessere User Stories schreiben?

Wie alle Arten der Wissensarbeit ist auch das Aufschreiben von User Stories (oder Softwareanforderungen) fehleranfällig. Diese Fehler müssen behoben werden, bevor die Software entwickelt wird. Andernfalls wird es sehr zeitaufwändig und kostspielig, sie erst einmal zu beheben. Es ist wahrscheinlicher, dass eine von einer Person geschriebene User Story von ihren Lesern möglicherweise falsch interpretiert wird.