Specification by Example to z jednej strony synonim, a z drugiej kluczowa praktyka Behavior-Driven Developmentu. I choć w teorii jej zadaniem było zbliżenie świata biznesu z branżą IT, praktyka pokazuje, że niewiele zespołów deweloperskich potrafi zaangażować „business people” we wspólne prace nad specyfikacją i kryteriami jakości. Prezentacja za pomocą praktycznego przykładu pokazuje, w jaki sposób język Gherkin może być wykorzystany przez analityków biznesowych do tworzenia specyfikacji naprawdę łączącej biznes z zespołem wdrożeniowym.

1. Specification by Example w praktyce
Krzysztof Trzewiczek
Singup, Business Analysis Consulting

2. Wielkie przegrane
Commercial organisations across the European Union lost 142 billion EUR on
failed IT projects in 2004 alone, mostly because of poor alignment with
business objectives or business strategies becoming obsolete during delivery.
Gojko Adzic, Impact Mapping

3. DSL czytelny dla biznesu
If business people are able to look at the DSL code and understand it, then we can
build a deep and rich communication channel between software development
and the underlying domain.
Martin Fowler, http://martinfowler.com/bliki/BusinessReadableDSL.html

4. Język Gherkin
Czytelny dla biznesu DSL, który pozwala opisywać zachowanie aplikacji nie
dotykając tego, jak to zachowanie jest zaimplementowane.
Gherkin służy dwóm celom — dokumentacji i testom automatycznym.
Cucumber's GitHub Wiki

5. Gherkin na GitHubie
Scenariusz o nazwie 31 posiada:
z backgroundem, który posiada:
w pliku długości 3994 lini kodu.
194
10
84
90
Linie kodu
When
Then
And
58
3
14
Linie kodu
Given
And

6. Gherkin na GitHubie (ciąg dalszy)
Scenariusz o nazwie I can create a booking posiada:
w pliku zawierającym tylko jeden dodatkowy scenariusz:
I can create a booking programmatically.
124
4
9
28
33
Linie kodu
Given
When
Then
And

7. Specyfikuj biznes!
Specyfikacja to kanał łączący biznes z ekipą wdrażającą produkt.
Właśnie z tego powodu specyfikacja powinna odzwierciedlać
problemy biznesowe, które aplikacja stara się rozwiązać,
a nie techniczne zachowanie systemu.

8. Co Driven Development?
BDD nie powinno oznaczać Behavior-Driven Development.
BDD powinno oznaczać Business-Driven Development.

9. Piekło nazw i skrótowców
The fact that the same practices have so many names reflects the huge amount
of innovation in this field at the moment. It also reflects the fact that the practices
described in this book impact the ways teams approach specifications,
development, and testing.
Gojko Adzic, Specification by Example

10. Przykładowa funkcjonalność
Dashboard dla doradcy ubezpieczeniowego. W praktyce, doradca
reprezentuje swoich klientów przed firmami ubezpieczeniowymi
oraz zarządza ich umowami.
Funkcjonalność, o której mowa, to edycja profilu użytkownika.

11. Typowe Spec by Example
Feature: Profile settings
In order to edit my personal data
As a regular user
I want to be able to update my user profile
Scenario: I want to change my name
Given I go to the landing page
And I sign in
And I click on the “Edit your profile” button
When I change my name to “Jane Doe”
And I submit the form
Then my name is changed to Jane Doe
Scenario: I want to change my email
-- code hidden --
Scenario: I want to change my password
-- code hidden --
@edge-case
Scenario: My new email is already taken
-- code hidden --

12. Problemy
1. Wyciek interfejsu do specyfikacji
2. Skupienie się na rozwiązaniach, a nie wymaganiach
3. Specyfikacja opisuje strukturę systemu, a nie zasady biznesowe

13. Problem 1: Interfejs w specyfikacji
Feature: Profile settings
In order to edit my personal data
As a regular user
I want to be able to update my user profile
Scenario: I want to change my name
Given I go to the landing page
And I sign in
And I click on the “Edit your profile” button
When I change my name to “Jane Doe”
And I submit the form
Then my name is changed to Jane Doe
Scenario: I want to change my email
-- code hidden --
Scenario: I want to change my password
-- code hidden --
@edge-case
Scenario: My new email is already taken
-- code hidden --

14. Problem 2: Rozwiązania zamiast wymagań
Feature: Profile settings
In order to edit my personal data
As a regular user
I want to be able to update my user profile
Scenario: I want to change my name
Given I go to the landing page
And I sign in
And I click on the “Edit your profile” button
When I change my name to “Jane Doe”
And I submit the form
Then my name is changed to Jane Doe
Scenario: I want to change my email
-- code hidden --
Scenario: I want to change my password
-- code hidden --
@edge-case
Scenario: My new email is already taken
-- code hidden --

15. Problem 3: Struktura systemu, a nie biznesu
Feature: Profile settings
In order to edit my personal data
As a regular user
I want to be able to update my user profile
Scenario: I want to change my name
Given I go to the landing page
And I sign in
And I click on the “Edit your profile” button
When I change my name to “Jane Doe”
And I submit the form
Then my name is changed to Jane Doe
Scenario: I want to change my email
-- code hidden --
Scenario: I want to change my password
-- code hidden --
@edge-case
Scenario: My new email is already taken
-- code hidden --

16. Pierwsza iteracja zmian: Rozwiązujemy
problemy
1. Rozdzielenie tożsamości biznesowej od użytkownika
2. Pozbycie się interfejsu użytkownika ze specyfikacji
3. Wprowadzenie kontekstu biznesowego produktu

17. Krok 1: Rozdzielenie tożsamości biznesowej
od użytkownika
Ability: Keeping business identity up to date
In order to keep my business identity up to date
As a business consultant
I want to edit my personal data
Business Need: Account security
In order to make sure my account is secure
As a user
I want to change my password

18. Krok 2: Pozbycie się interfejsu użytkownika
ze specyfikacji
Scenario: I need to change my name
Given I need to update my business identity
When I change my name to Tamara Ackerman-Smith
Then all the messages to my clients are signed as “Tamara Ackerman-Smith”
Scenario: I need to change my email
Given my account uses tamara.ackerman@asia.ibm.com email
And I need to update my business identity
When I change my email to tamara.ackerman@europe.ibm.com
Then from now on, all the messages to my clients are sent from
tamara.ackerman@europe.ibm.com address
And all my clients are notified about my new email
Scenario: My new email is already taken
-- code hidden --

19. Krok 3: Wprowadzenie kontekstu
biznesowego produktu
Ability: Keeping business identity up to date
In order to keep my business identity up to date
As a business consultant
I want to edit my personal data
Profile settings are strictly connected to work-related activities of business
consultants. Their clients recognize them by their names; in case of longer
relationships, they type their emails almost automatically.
Scenario: I need to change my name
Tamara Ackerman changes her name to Tamara Ackerman-Smith.
-- code hidden --
Scenario: I need to change my email
Tamara Ackerman is transferred to the European branch from the Asian branch.
-- code hidden --
Scenario: My new email is already taken
Tamara Ackerman is transferred to the European branch. Her new management
created a separate account for her, not knowing she’s already got one.
-- code hidden --

20. Druga iteracja zmian: odkrywanie ukrytych
możliwości
Business Need: Account security
In order to make sure my account is secure
As a user
I want to change my password
To ensure that every user is treated with the best care possible when she’s
concerned about her account’s security, we use the customer service department
and the live chat feature. Our consultants can not only change her password,
but also educate her about security and make sure her concerns are addressed
adequately.
Scenario: I need to change my password
Given I need to change my password
When I contact with the customer service department
Then my ticket gets the highest priority

21. Co udało się osiągnąć?
1. Wprowadzić do wymagań kontekst biznesowy w jakim produkt
funkcjonuje.
2. Pozbyć się rozwiązań ze specyfikacji wymagań.
3. Wykorzystać istniejące rozwiązania, by osiągnąć te same cele biznesowe
mniejszym nakładem pracy zespołu.

22. Będzie książka kucharska
Kamil Nicieja, Krzysztof Trzewiczek
Gherkin Patterns: Practicing Specification by Example
Writing
Fake-world data
Almost equal
Quality feature
Asteroids
Communication
Various artists
Conversation token
Hands-off business
Process
Iterative process
Too many changes
Automation for automation’s sake
Traceability
30 praktycznych przykładów
11 wzorców specyfikacji
3 obszary zastosowania

23. Krzysztof Trzewiczek
krzysztof@singup.pl