Oprogramowanie może być wytwarzane w oparciu o różne pomysły. Czasem napędzane jest przez powstającą dokumentację, czasem przez testy, a innym razem przez zachowanie samego systemu. Wśród software house’ów popularne stało się stosowanie BDD, ponieważ, przy budowaniu produktu, skupia się ono bardziej na potrzebach biznesowych niż na technicznych aspektach. Często stosowane jest także jako dodatkowa warstwa przy automatyzacji testów, gdyż wyniki ich wykonania są dzięki temu prezentowane w bardziej zrozumiały dla biznesu sposób. Skuteczne używanie BDD wymaga jednak dobrego przygotowania i czasu na wdrożenie tej techniki — w związku z tym istnieje duża przestrzeń do pomyłek i potknięć. W czasie prelekcji Łukasz odpowiadał na pytanie czym jest BDD i jak go dobrze używać — opowiedział, czego nauczyły go dotychczasowe doświadczenia projektowe w tym temacie.

3. BDD & Automation
(Un)healthy
case study

5. it’s

6. right

7. there

8. in the definition!

9. Behaviour
Driven
DEVELOPMENT!

10. Disease #1 - common
symptoms
• No discussions at all regarding the
feature…
• …or just pure technical discussions
• Architecture discussed only in
small teams
• Starting BDD scenarios /
automation without fully
understanding the need
• “It works on QA/DEV/PRE-PROD
but not on production”
• “It must be backend issue. let’s
report it”

11. Disease #1:
not knowing the behaviour well enough

13. Disease #2 - common
symptoms
• Gherkin/Cucumber etc. as a
“way for business to
understand our tests”
• Really long scenarios with lots
of steps
• When-Then-When-Then-etc…

14. Disease #2:
describing implementation details
as a behaviour

15. Disease #3 - common
symptoms
• Testers writing Gherkin
scenarios
• Business assesing the test
scenario
• PM/PdO gathering and
undestanding all the details
regarding the behaviour

16. Disease #3:
assigning wrong people to tasks

18. Disease #4 - common
symptoms
• Frequent “Why are these tests
failing” from business
• Frequent “Why is it all red
again” from DEV
• “We need to fix these
automated tests” from
business

19. Disease #4:
reporting everything to everyone

22. Wanna know how to use
automation with BDD?
Here are some tips how to do it well

23. ATDD: Tips & tricks
• always remember BDD is not a testing
technique. It’s a design technique
• when describing scenarios
concentrate on system behaviour
• avoid at all cost including
implementation details in the scenario
• for high-level decsription involve
business
• for automated scripts involve QA
engineers
• remember to tailor and aim your
reporting well