BDD - Spezifikationen am Beispiel

Laut Gojko Adzic, dem Autor von 'Specification by Example', ist Specification by Example eine Reihe von Prozessmustern, die das Ändern von Softwareprodukten erleichtern, um sicherzustellen, dass das richtige Produkt effizient geliefert wird. “

Die Spezifikation anhand eines Beispiels ist ein kollaborativer Ansatz zur Definition der Anforderungen und geschäftsorientierten Funktionstests für Softwareprodukte, der auf der Erfassung und Veranschaulichung von Anforderungen anhand realistischer Beispiele anstelle abstrakter Aussagen basiert.

Spezifikation am Beispiel - Übersicht

Das Ziel von Specification by Example besteht darin, sich auf die Entwicklung und Bereitstellung priorisierter, überprüfbarer Geschäftsanforderungen zu konzentrieren. Während das Konzept der Spezifikation durch Beispiele an sich relativ neu ist, ist es lediglich eine Neuformulierung bestehender Praktiken.

Es unterstützt ein sehr spezifisches, prägnantes Vokabular, das als allgegenwärtige Sprache bekannt ist und -

• Aktiviert ausführbare Anforderungen.

• Wird von allen im Team verwendet.

• Wird von einem funktionsübergreifenden Team erstellt.

• Erfasst das Verständnis aller.

Die Spezifikation anhand eines Beispiels kann als direkte Eingabe für die Erstellung automatisierter Tests verwendet werden, die die Geschäftsdomäne widerspiegeln. Daher liegt der Schwerpunkt der Spezifikation anhand eines Beispiels auf dem Aufbau des richtigen Produkts und dem Aufbau des richtigen Produkts.

Zweck der Spezifikation durch Beispiel

Das Hauptziel von Specification by Example ist es, das richtige Produkt zu bauen. Es konzentriert sich auf das gemeinsame Verständnis und schafft so eine einzige Quelle der Wahrheit. Es ermöglicht die Automatisierung von Akzeptanzkriterien, sodass der Schwerpunkt eher auf der Fehlervermeidung als auf der Fehlererkennung liegt. Es fördert auch den frühen Test, um die Defekte frühzeitig zu finden.

Verwendung von SbE

Die Spezifikation anhand eines Beispiels wird verwendet, um das erwartete Systemverhalten zu veranschaulichen, das den Geschäftswert beschreibt. Die Darstellung erfolgt anhand konkreter und realer Beispiele. Diese Beispiele werden verwendet, um ausführbare Anforderungen zu erstellen, die -

• Ohne Übersetzung testbar.

• In Live-Dokumentation erfasst.

Im Folgenden sind die Gründe aufgeführt, warum wir Beispiele verwenden, um bestimmte Spezifikationen zu beschreiben:

• Sie sind leichter zu verstehen.

• Sie sind schwerer falsch zu interpretieren.

Vorteile von SbE

Die Vorteile der Verwendung der Spezifikation anhand eines Beispiels sind:

• Erhöhte Qualität

• Reduzierter Abfall

• Reduziertes Risiko von Produktionsfehlern

• Konzentrierte Anstrengung

• Änderungen können sicherer vorgenommen werden

• Verbesserte Geschäftsbeteiligung

Anwendungen von SbE

Spezifikation durch Beispiel finden Anwendungen in -

• Entweder komplexes Geschäft oder komplexe Organisation.

• Funktioniert nicht gut bei rein technischen Problemen.

• Funktioniert nicht gut für UI-fokussierte Softwareprodukte.

• Kann auch auf Legacy-Systeme angewendet werden.

SbE- und Abnahmetests

Die Vorteile der Spezifikation durch Beispiele in Bezug auf Abnahmetests sind:

• Eine einzige Abbildung wird sowohl für detaillierte Anforderungen als auch für Tests verwendet

• Der Fortschritt des Projekts erfolgt in Form von Abnahmetests -

  • Jeder Test dient dazu, ein Verhalten zu testen.

  • Ein Test besteht entweder ein Verhalten oder nicht.

  • Ein bestehender Test zeigt an, dass das jeweilige Verhalten abgeschlossen ist.

  • Wenn für ein Projekt, für das 100 Verhaltensweisen abgeschlossen werden müssen, 60 Verhaltensweisen abgeschlossen sind, ist es zu 60% abgeschlossen.

• Tester wechseln von der Fehlerbehebung zur Fehlervermeidung und tragen zum Design der Lösung bei.

• Die Automatisierung ermöglicht ein sofortiges Verständnis der Auswirkungen einer Anforderungsänderung auf die Lösung.

Spezifikation am Beispiel - Was dies für verschiedene Rollen bedeutet

Das Ziel von Specification by Example ist es, die Zusammenarbeit aller im Team, einschließlich des Kunden, während des gesamten Projekts zu fördern, um geschäftlichen Nutzen zu erzielen. Jeder verwendet zum besseren Verständnis denselben Wortschatz.

Rolle	Verwendung von SbE
Business Analyst	Die Anforderungen sind eindeutig und ohne funktionale Lücken. Entwickler lesen tatsächlich die Spezifikationen.
Entwickler	Entwickler verstehen besser, was entwickelt wird. Der Entwicklungsfortschritt wird besser verfolgt, indem die korrekt entwickelten Spezifikationen gezählt werden.
Prüfer	Tester verstehen besser, was getestet wird. Tester sind von Anfang an involviert und spielen eine Rolle im Design. Tester arbeiten eher an der Fehlervermeidung als an der Fehlererkennung.
Jeder	Durch die Identifizierung von Fehlern von Anfang an wird Zeit gespart. Ein Qualitätsprodukt wird von Anfang an hergestellt.

SbE - Eine Reihe von Prozessmustern

Wie wir am Anfang dieses Kapitels gesehen haben, wird Spezifikation durch Beispiel als eine Reihe von Prozessmustern definiert, die Änderungen an Softwareprodukten erleichtern, um sicherzustellen, dass das richtige Produkt effizient geliefert wird.

Die Prozessmuster sind -

• Kollaborative Spezifikation

• Veranschaulichung von Spezifikationen anhand von Beispielen

• Verfeinerung der Spezifikation

• Beispiele automatisieren

• Häufig validieren

• Lebende Dokumentation

Kollaborative Spezifikation

Die Ziele der kollaborativen Spezifikation sind:

• Holen Sie sich die verschiedenen Rollen in einem Team, um ein gemeinsames Verständnis und ein gemeinsames Vokabular zu haben.

• Binden Sie alle an dem Projekt Beteiligten ein, damit sie ihre unterschiedlichen Perspektiven zu einem Feature einbringen können.

• Stellen Sie die gemeinsame Kommunikation und das Eigentum an den Funktionen sicher.

Diese Ziele werden in einem Spezifikationsworkshop erreicht, der auch als Drei-Amigos-Treffen bekannt ist. Die drei Amigos sind BA, QA und der Entwickler. Obwohl es andere Rollen im Projekt gibt, wären diese drei von der Definition bis zur Bereitstellung der Funktionen verantwortlich und rechenschaftspflichtig.

During the meeting −

• Der Business Analyst (BA) präsentiert die Anforderungen und Tests für eine neue Funktion.

• Die drei Amigos (BA, Entwickler und Qualitätssicherung) diskutieren die neue Funktion und überprüfen die Spezifikationen.

• Die Qualitätssicherung und der Entwickler identifizieren auch die fehlenden Anforderungen.

• Die drei Amigos

  • Verwenden Sie ein gemeinsames Modell in einer allgegenwärtigen Sprache.

  • Verwenden Sie das Domain-Vokabular (bei Bedarf wird ein Glossar gepflegt).

  • Suchen Sie nach Unterschieden und Konflikten.

• Springen Sie an dieser Stelle nicht zu den Implementierungsdetails.

• Erreichen Sie einen Konsens darüber, ob ein Feature ausreichend spezifiziert wurde.

• Ein gemeinsames Gefühl für Anforderungen und Testbesitz erleichtert die Qualitätsspezifikationen

• Die Anforderungen werden als Szenarien dargestellt, die explizite, eindeutige Anforderungen enthalten. Ein Szenario ist ein Beispiel für das Systemverhalten aus Anwendersicht.

Veranschaulichung der Spezifikation anhand von Beispielen

Szenarien werden mithilfe der Given-When-Then-Struktur angegeben, um eine testbare Spezifikation zu erstellen.

Given <einige Voraussetzungen>

And <zusätzliche Voraussetzungen> Optional

When <eine Aktion / ein Auslöser tritt auf>

Then <einige Post-Bedingung>

And <zusätzliche Postbedingungen> Optional

Diese Spezifikation ist ein Beispiel für ein Verhalten des Systems. Es stellt auch ein Akzeptanzkriterium des Systems dar.

Das Team diskutiert die Beispiele und das Feedback wird einbezogen, bis Einigkeit darüber besteht, dass die Beispiele das erwartete Verhalten der Funktion abdecken. Dies gewährleistet eine gute Testabdeckung.

Verfeinerung der Spezifikation

Um eine Spezifikation zu verfeinern,

• Schreiben Sie die Beispiele genau. Wenn ein Beispiel komplex wird, teilen Sie es in einfachere Beispiele auf.

• Konzentrieren Sie sich auf die Geschäftsperspektive und vermeiden Sie technische Details.

• Berücksichtigen Sie sowohl positive als auch negative Bedingungen.

• Halten Sie sich an das domänenspezifische Vokabular.

• Besprechen Sie die Beispiele mit dem Kunden.

  • Wählen Sie Gespräche, um dies zu erreichen.

  • Betrachten Sie nur die Beispiele, an denen der Kunde interessiert ist. Dies ermöglicht nur die Erstellung des erforderlichen Codes und vermeidet, dass jede mögliche Kombination abgedeckt wird, die möglicherweise nicht erforderlich ist

• Um sicherzustellen, dass das Szenario erfolgreich ist, müssen alle Testfälle für dieses Szenario erfolgreich sein. Verbessern Sie daher die Spezifikationen, um sie testbar zu machen. Die Testfälle können verschiedene Bereiche und Datenwerte (Grenz- und Eckfälle) sowie verschiedene Geschäftsregeln enthalten, die zu Datenänderungen führen.

• Geben Sie zusätzliche Geschäftsregeln wie komplexe Berechnungen, Datenmanipulation / -transformation usw. an.

• Fügen Sie nicht funktionierende Szenarien (z. B. Leistung, Last, Benutzerfreundlichkeit usw.) als Beispielspezifikation hinzu

Beispiele automatisieren

Die Automatisierungsschicht muss sehr einfach gehalten werden - nur die Verkabelung der Spezifikation mit dem zu testenden System. Sie können ein Werkzeug dafür verwenden.

Führen Sie die Testautomatisierung mit DSL (Domain Specific Language) durch und zeigen Sie eine klare Verbindung zwischen Ein- und Ausgängen. Konzentrieren Sie sich auf die Spezifikation und nicht auf das Skript. Stellen Sie sicher, dass die Tests präzise, ​​leicht verständlich und überprüfbar sind.

Häufige Validierung

Nehmen Sie bei jeder Änderung (Hinzufügung / Änderung) eine Beispielvalidierung in Ihre Entwicklungspipeline auf. Es gibt viele Techniken und Werkzeuge, die angewendet werden können (und sollten), um die Qualität eines Produkts sicherzustellen. Sie drehen sich um drei Schlüsselprinzipien:Test Early, Test Well und Test Often.

Führen Sie die Tests häufig durch, damit Sie die schwachen Glieder identifizieren können. Die Beispiele, die das Verhalten darstellen, helfen dabei, den Fortschritt zu verfolgen, und ein Verhalten wird erst nach Abschluss der entsprechenden Testdurchläufe als vollständig bezeichnet.

Lebende Dokumentation

Halten Sie die Spezifikationen so einfach und kurz wie möglich. Organisieren Sie die Spezifikationen und entwickeln Sie sie im Verlauf der Arbeit weiter. Machen Sie die Dokumentation für alle im Team zugänglich.

Spezifikation durch beispielhafte Prozessschritte

Die Abbildung zeigt die Prozessschritte in Spezifikation anhand eines Beispiels.

Anti-Muster

Anti-Patterns sind bestimmte Muster in der Softwareentwicklung, die als schlechte Programmierpraxis angesehen werden. Im Gegensatz zu Entwurfsmustern, bei denen es sich um gängige Ansätze für häufig auftretende Probleme handelt, die formalisiert wurden und allgemein als gute Entwicklungspraxis angesehen werden, sind Anti-Muster das Gegenteil und unerwünscht

Anti-Muster werfen verschiedene Probleme auf.

Anti-Muster	Probleme
Keine Zusammenarbeit	Viele Annahmen Falsche Sache bauen Falsche Sache testen Nicht bekannt, wann der Code fertig ist
Nicht bekannt, wann der Code fertig ist	Schwer zu wartende Tests Schwer zu verstehende Spezifikation Interessensverlust von Wirtschaftsvertretern
Zu detaillierte oder zu UI-zentrierte Beispiele	Schwer zu wartende Tests Schwer verständliche Spezifikationen Interessensverlust von Wirtschaftsvertretern
Aufwand unterschätzen erforderlich	Die Teams denken, dass sie gescheitert sind und werden früh enttäuscht

Lösung der Probleme - Qualität

Qualität kann sichergestellt werden, indem die Anti-Patterns im Auge behalten werden. Um die durch Anti-Patterns verursachten Probleme zu minimieren, sollten Sie:

• Treffen Sie sich, um anhand von Beispielen zu spezifizieren.

• Bereinigen und verbessern Sie die Beispiele.

• Schreiben Sie einen Code, der den Beispielen entspricht

• Automatisieren Sie die Beispiele und stellen Sie sie bereit.

• Wiederholen Sie den Ansatz für jede User Story.

Die Probleme aufgrund von Anti-Mustern zu lösen bedeutet, sich an - zu halten.

• Collaboration.

• Konzentration auf was.

• Konzentration auf das Geschäft.

• Sei vorbereitet.

Lassen Sie uns verstehen, was jeder der oben genannten Punkte bedeutet.

Zusammenarbeit

In Zusammenarbeit -

• Geschäftsleute, Entwickler und Tester geben Input aus ihrer eigenen Perspektive.

• Automatisierte Beispiele beweisen, dass das Team das Richtige gebaut hat.

• Der Prozess ist wertvoller als die Tests selbst.

Konzentration auf was

Sie müssen sich auf die Frage konzentrieren - was. Während Sie sich auf "was" konzentrieren -

• Versuchen Sie nicht, alle möglichen Fälle abzudecken.

• Vergessen Sie nicht, verschiedene Arten von Tests durchzuführen.

• Halten Sie Beispiele so einfach wie möglich.

• Beispiele sollten für die Benutzer des Systems leicht verständlich sein.

• Werkzeuge sollten in den Workshops keine wichtige Rolle spielen.

Konzentration auf das Geschäft

Sich auf das Geschäft konzentrieren -

• Halten Sie die Spezifikation bei Geschäftsabsicht.

• Beziehen Sie Unternehmen in die Erstellung und Überprüfung von Spezifikationen ein.

• Blenden Sie alle Details in der Automatisierungsebene aus.

Sei vorbereitet

Seien Sie auf Folgendes vorbereitet:

• Die Vorteile sind nicht sofort ersichtlich, selbst wenn die Teampraktiken geändert werden.

• Die Einführung von SbE ist eine Herausforderung.

• Benötigt Zeit und Investitionen.

• Automatisierte Tests sind nicht kostenlos.

Werkzeuge

Die Verwendung von Werkzeugen ist für die Spezifikation anhand eines Beispiels nicht obligatorisch, obwohl in der Praxis mehrere Werkzeuge verfügbar sind. Es gibt Fälle, die nach Spezifikation anhand eines Beispiels auch ohne Verwendung eines Werkzeugs erfolgreich sind.

Die folgenden Tools unterstützen die Spezifikation anhand eines Beispiels -

• Cucumber

• SpecFlow

• Fitnesse

• Jbehave

• Concordion

• Behat

• Jasmine

• Relish

• Speclog