BDD - Specyfikacje na przykładzie

Według Gojko Adzicia, autora „Specification by Example”, Specification by Example to zestaw wzorców procesowych, które ułatwiają zmianę oprogramowania w celu zapewnienia, że właściwy produkt jest dostarczany efektywnie. ”

Specification by Example to oparte na współpracy podejście do definiowania wymagań i testów funkcjonalnych zorientowanych na biznes dla oprogramowania, oparte na wychwytywaniu i ilustrowaniu wymagań przy użyciu realistycznych przykładów zamiast abstrakcyjnych stwierdzeń.

Specyfikacja na przykładzie - przegląd

Celem Specyfikacji na przykładzie jest skupienie się na opracowaniu i dostarczeniu uszeregowanych pod względem ważności, weryfikowalnych wymagań biznesowych. Chociaż sama koncepcja specyfikacji przez przykład jest stosunkowo nowa, jest po prostu przeformułowaniem istniejących praktyk.

Obsługuje bardzo specyficzne, zwięzłe słownictwo znane jako język wszechobecny, który -

Włącza wymagania wykonywalne.
Jest używany przez wszystkich w zespole.
Jest tworzony przez wielofunkcyjny zespół.
Przechwytuje zrozumienie każdego.

Specyfikacja według przykładu może służyć jako bezpośredni wkład w tworzenie testów automatycznych, które odzwierciedlają domenę biznesową. Tak więc specyfikacja przez przykład koncentruje się na budowaniu właściwego produktu i budowaniu właściwego produktu.

Cel specyfikacji na przykładzie

Podstawowym celem Specyfikacji przez Przykład jest zbudowanie odpowiedniego produktu. Koncentruje się na wspólnym zrozumieniu, ustanawiając w ten sposób jedno źródło prawdy. Umożliwia automatyzację kryteriów akceptacji, tak aby skupić się na zapobieganiu defektom, a nie na ich wykrywaniu. Promuje również wczesne testowanie, aby wcześnie wykryć defekty.

Korzystanie z SbE

Specyfikacja według przykładu służy do zilustrowania oczekiwanego zachowania systemu, które opisuje wartość biznesową. Ilustracja przedstawia konkretne przykłady z życia. Te przykłady są używane do tworzenia wykonywalnych wymagań, które są -

Testowalne bez tłumaczenia.
Przechwycone w dokumentacji na żywo.

Oto powody, dla których używamy przykładów do opisania poszczególnych specyfikacji -

Są łatwiejsze do zrozumienia.
Trudniej je źle zinterpretować.

Zalety SbE

Zalety korzystania ze specyfikacji na przykładzie:

Wyższa jakość
Mniejsza ilość odpadów
Zmniejszone ryzyko wad produkcyjnych
Skoncentrowany wysiłek
Zmiany można wprowadzać bezpieczniej
Lepsze zaangażowanie biznesowe

Zastosowania SbE

Specyfikacja według przykładu znajdź aplikacje w -

Albo złożona firma, albo złożona organizacja.
Nie działa dobrze w przypadku problemów czysto technicznych.
Nie działa dobrze w przypadku oprogramowania ukierunkowanego na interfejs użytkownika.
Może być również stosowany w starszych systemach.

SbE i testy akceptacyjne

Zalety specyfikacji przez przykład w zakresie testów akceptacyjnych to:

Na jednej ilustracji przedstawiono szczegółowe wymagania i testy
Postęp projektu w zakresie testów akceptacyjnych -
- Każdy test ma na celu sprawdzenie zachowania.
- Test zalicza zachowanie lub nie.
- Zdany test oznacza, że określone zachowanie zostało zakończone.
- Jeśli projekt, który wymaga ukończenia 100 zachowań, ma ukończonych 60 zachowań, to jest ukończony w 60%.
Testerzy przechodzą od naprawiania defektów do zapobiegania defektom i uczestniczą w projektowaniu rozwiązania.
Automatyzacja umożliwia natychmiastowe zrozumienie wpływu zmiany wymagań na rozwiązanie.

Specyfikacja na przykładzie - co to oznacza dla różnych ról

Celem Specyfikacji na przykładzie jest promowanie współpracy wszystkich członków zespołu, w tym klienta w całym projekcie, w celu dostarczenia wartości biznesowej. Dla lepszego zrozumienia wszyscy używają tego samego Słownictwa.

Rola	Korzystanie z SbE
Analityk Biznesowy	Wymagania są jednoznaczne i pozbawione luk funkcjonalnych. Deweloperzy faktycznie przeczytali specyfikacje.
Deweloper	Programiści lepiej rozumieją, co jest rozwijane. Postęp rozwoju jest lepiej śledzony, licząc specyfikacje, które zostały opracowane poprawnie.
Próbnik	Testerzy lepiej rozumieją, co jest testowane. Testerzy są zaangażowani od samego początku i odgrywają rolę w projektowaniu. Testerzy pracują raczej w kierunku zapobiegania defektom niż ich wykrywania.
Wszyscy	Oszczędność czasu dzięki identyfikacji błędów od samego początku. Od samego początku wytwarzany jest produkt wysokiej jakości.

SbE - zestaw wzorców procesu

Jak widzieliśmy na początku tego rozdziału, Specyfikacja na podstawie przykładu jest zdefiniowana jako zestaw wzorców procesowych, które ułatwiają wprowadzanie zmian w oprogramowaniu w celu zapewnienia wydajnego dostarczania właściwego produktu.

Wzorce procesów to -

Wspólna specyfikacja
Zilustrowanie specyfikacji za pomocą przykładów
Dopracowanie specyfikacji
Automatyzacja przykładów
Częste sprawdzanie poprawności
Żywa dokumentacja

Specyfikacja dotycząca współpracy

Cele wspólnej specyfikacji to:

Zdobądź różne role w zespole, aby mieć wspólne zrozumienie i wspólne słownictwo.
Zaangażuj wszystkich w projekt, aby mogli wnieść swój wkład z różnych perspektyw na temat funkcji.
Zapewnij współdzieloną komunikację i własność funkcji.

Cele te są osiągane podczas warsztatów specyfikacji znanych również jako spotkanie Trzech Amigos. Trzej Amigos to BA, QA i programista. Chociaż w projekcie są inne role, te trzy osoby byłyby odpowiedzialne i rozliczane od zdefiniowania do dostarczenia funkcji.

During the meeting −

Analityk biznesowy (BA) przedstawia wymagania i testy nowej funkcji.
Trzej Amigos (licencjat, deweloper i QA) omawiają nową funkcję i przeglądają specyfikacje.
Kontrola jakości i programista również identyfikują brakujące wymagania.
Trzej Amigos
- Wykorzystaj wspólny model, używając wszechobecnego języka.
- Używaj słownictwa dziedzinowego (w razie potrzeby utrzymywany jest słownik).
- Szukaj różnic i konfliktów.
Na tym etapie nie przechodź do szczegółów implementacji.
Osiągnij konsensus co do tego, czy funkcja została określona wystarczająco.
Wspólne poczucie wymagań i własności testów ułatwiają specyfikacje jakości
Wymagania są przedstawiane jako scenariusze, które zapewniają wyraźne, jednoznaczne wymagania. Scenariusz jest przykładem zachowania systemu z perspektywy użytkowników.

Zilustrowanie specyfikacji za pomocą przykładów

Scenariusze są określane przy użyciu struktury Given-When-Then w celu utworzenia testowalnej specyfikacji -

Given <pewne warunki wstępne>

And <dodatkowe warunki wstępne> Optional

When <następuje akcja / wyzwalacz>

Then <stan postu>

And <dodatkowe warunki ogłoszenia> Optional

Ta specyfikacja jest przykładem zachowania systemu. Stanowi również kryterium akceptacji systemu.

Zespół omawia przykłady, a informacje zwrotne są uwzględniane, dopóki nie zostanie uzgodnione, że przykłady obejmują oczekiwane zachowanie funkcji. Zapewnia to dobre pokrycie testu.

Dopracowanie specyfikacji

Aby udoskonalić specyfikację,

Podaj dokładne przykłady. Jeśli przykład okaże się złożony, podziel go na prostsze przykłady.
Skoncentruj się na perspektywie biznesowej i unikaj szczegółów technicznych.
Rozważ zarówno pozytywne, jak i negatywne warunki.
Przestrzegaj słownictwa specyficznego dla domeny.
Omów przykłady z klientem.
- Wybierz rozmowy, aby to osiągnąć.
- Weź pod uwagę tylko te przykłady, którymi interesuje się klient. Umożliwia to wytworzenie tylko wymaganego kodu i pozwala uniknąć pokrycia wszystkich możliwych kombinacji, które mogą nie być wymagane
Aby upewnić się, że scenariusz przejdzie pomyślnie, wszystkie przypadki testowe dla tego scenariusza muszą przejść. Dlatego ulepsz specyfikacje, aby były testowalne. Przypadki testowe mogą obejmować różne zakresy i wartości danych (przypadki graniczne i narożne), a także różne reguły biznesowe powodujące zmiany w danych.
Określ dodatkowe reguły biznesowe, takie jak złożone obliczenia, manipulacja / transformacja danych itp.
Uwzględnij scenariusze niefunkcjonalne (np. Wydajność, obciążenie, użyteczność itp.) Jako specyfikację według przykładu

Automatyzacja przykładów

Warstwa automatyzacji musi być bardzo prosta - wystarczy podłączyć specyfikację do testowanego systemu. Możesz użyć narzędzia do tego samego.

Wykonuj automatyzację testów za pomocą języka specyficznego dla domeny (DSL) i pokaż wyraźne połączenie między wejściami i wyjściami. Skoncentruj się na specyfikacji, a nie na skrypcie. Upewnij się, że testy są dokładne, łatwe do zrozumienia i testowalne.

Częste sprawdzanie poprawności

Uwzględnij przykładową walidację w swoim potoku programistycznym przy każdej zmianie (dodaniu / modyfikacji). Istnieje wiele technik i narzędzi, które można (i należy) zastosować w celu zapewnienia jakości produktu. Obracają się wokół trzech kluczowych zasad:Test Early, Test Well i Test Often.

Wykonuj testy często, aby móc zidentyfikować słabe ogniwa. Przykłady przedstawiające zachowania pomagają śledzić postępy i mówi się, że zachowanie jest kompletne dopiero po przejściu odpowiedniego testu.

Żywa dokumentacja

Staraj się, aby specyfikacje były tak proste i krótkie, jak to tylko możliwe. Zorganizuj specyfikacje i rozwijaj je w miarę postępu prac. Udostępnij dokumentację wszystkim członkom zespołu.

Specyfikacja według przykładowych etapów procesu

Ilustracja przedstawia etapy procesu w specyfikacji na przykładzie.

Anty-wzory

Anty-wzorce to pewne wzorce w tworzeniu oprogramowania, które są uważane za złą praktykę programistyczną. W przeciwieństwie do wzorców projektowych, które są powszechnym podejściem do typowych problemów, które zostały sformalizowane i są ogólnie uważane za dobrą praktykę rozwojową, anty-wzorce są przeciwieństwem i są niepożądane

Anty-wzorce powodują różne problemy.

Anty-wzór	Problemy
Brak współpracy	Wiele założeń Budowanie złej rzeczy Testowanie złej rzeczy Nieświadomy zakończenia kodu
Nieświadomy zakończenia kodu	Trudne do utrzymania testy Trudna do zrozumienia specyfikacja Utrata zainteresowania ze strony przedstawicieli biznesu
Zbyt szczegółowe lub zbyt skoncentrowane na interfejsie przykłady	Trudne do utrzymania testy Trudne do zrozumienia specyfikacje Utrata zainteresowania ze strony przedstawicieli biznesu
Wymagany niedoceniany wysiłek	Zespoły myślą, że zawiodły i wcześnie się rozczarowują

Rozwiązanie problemów - Jakość

Jakość można zapewnić, obserwując anty-wzorce. Aby zminimalizować problemy stwarzane przez anty-wzorce, powinieneś -

Zbierzcie się, aby określić na podstawie przykładów.
Oczyść i popraw przykłady.
Napisz kod, który spełnia podane przykłady
Zautomatyzuj przykłady i wdrażaj.
Powtórz to podejście dla każdej historyjki użytkownika.

Aby rozwiązać problemy spowodowane anty-wzorcami, oznacza przestrzeganie -

Collaboration.
Skupiając się na czym.
Koncentrując się na biznesie.
Być przygotowanym.

Zrozummy, co oznacza każde z powyższych.

Współpraca

We współpracy -

Ludzie biznesu, programiści i testerzy przekazują informacje z własnej perspektywy.
Zautomatyzowane przykłady dowodzą, że zespół zbudował to, co właściwe.
Proces jest cenniejszy niż same testy.

Skupiając się na czym

Musisz skupić się na pytaniu - „co”. Koncentrując się na tym „co” -

Nie próbuj opisywać wszystkich możliwych przypadków.
Nie zapomnij skorzystać z różnego rodzaju testów.
Utrzymuj przykłady tak proste, jak to tylko możliwe.
Przykłady powinny być łatwo zrozumiałe dla użytkowników systemu.
Narzędzia nie powinny odgrywać ważnej roli podczas warsztatów.

Koncentrując się na biznesie

Skupić się na biznesie -

Zachowaj specyfikację zgodną z zamierzeniami biznesowymi.
Uwzględnij biznes w tworzeniu i przeglądaniu specyfikacji.
Ukryj wszystkie szczegóły w warstwie automatyzacji.

Być przygotowanym

Przygotuj się na następujące -

Korzyści nie są widoczne od razu, nawet gdy zmieniają się praktyki zespołu.
Wprowadzenie SbE jest trudne.
Wymaga czasu i inwestycji.
Testowanie automatyczne nie jest darmowe.

Przybory

Korzystanie z narzędzi nie jest obowiązkowe w przypadku specyfikacji na podstawie przykładu, chociaż w praktyce dostępnych jest kilka narzędzi. Zdarzają się przypadki, w których postępowanie ze Specyfikacją przez Przykład przebiega pomyślnie, nawet bez użycia narzędzia.

Następujące narzędzia obsługują specyfikację według przykładu -

Cucumber
SpecFlow
Fitnesse
Jbehave
Concordion
Behat
Jasmine
Relish
Speclog