Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

BDD in Action - Automated Web Testing with WebDriver and Serenity

3,493 views

Published on

Slides from the London Agile Testing Meetup of November 25 2014:

John Ferguson Smart is a specialist in BDD, automated testing and software life cycle development optimization. John is a well-known speaker at many international conferences and events and an accomplished author (John's new book BDD in Action was published last month).

John presents a talk discussing how to write solid, reliable and maintainable automated web tests using the best-of-breed open source technologies like Selenium WebDriver, Serenity, JBehave and Cucumber.

Published in: Technology
  • Be the first to comment

BDD in Action - Automated Web Testing with WebDriver and Serenity

  1. 1. Demo BDD in Action John Ferguson Smart Wakaleo Consulting
  2. 2. Miyamoto Musashi Japan 1584 – 1645
  3. 3. Consultant Tr a i n e r Mentor Author Speaker Coder John Fer guson Smar t
  4. 4. What is BDD A typical BDD workflow What tools should I use? Effec@ve BDD automa@on BDD Gotchas
  5. 5. So what is this BDD thing? Using examples a shared understanding software that matters
  6. 6. Building the right software Hunting out value Automated Acceptance BDD Criteria API and code design Collaboration Living Documentation Building the software right
  7. 7. The business owner tells the business analyst what he wants 1 2 The business analyst writes a requirements document 3 The developer translates the requirements into software 4 The tester translates the requirements into test cases 5 The technical writer translates the software into functional and technical documentation BDD in a nutshell A traditional development process
  8. 8. The business owner and the business analyst have a conversation about what he needs. 1 2 3 The business analyst, the developer and the tester elaborate the requirements together. 4 The tester uses these scenarios as the basis for her tests 5 The automated tests provide feedback on progress and help document the application The scenarios guide the developer and act as automated tests They define requirements as structured, English-language format "scenarios" •Specifica@ons are elaborated collabora@vely •Specifica@ons use a common language •Executable specifica@ons provide fast feedback
  9. 9. Benefits of BDD BDD BDD in the real world -­‐ an example
  10. 10. BDD Gotchas 1 2 3 An@-­‐paKern 1 The business analyst writes the scenarios 4 and then gives them to the other team members.
  11. 11. 1 2 3 BDD Gotchas An@-­‐paKern 2 4 The tester writes the scenarios at the end to implement an automated test suite.
  12. 12. 1 2 3 4 5 BDD Gotchas An@-­‐paKern 3 The “Three Amigos” sessions don’t result in usable scenarios, so the developer invents them a=erwards.
  13. 13. 1 2 3 4 5 BDD Gotchas An@-­‐paKern 4 The scenarios are too UI-­‐centric or detail-­‐focused, and neglect to express the core business value.
  14. 14. BDD for high-level requirements
  15. 15. Frequent Flyer Application Goal: Encourage travellers to fly with Flying High airlines more often by allowing them to cumulate Frequent Flyer points that they can spend on cheaper flights. Goals Earning points from flights Capabili9es Earning points from spending with partners Viewing points earned Spending points on bookings Viewing current points balance Features View points needed to achieve the next status level Calculating points needed for a given destination
  16. 16. Calculating points needed for a given destination As a traveller I want to know how many points I need to go to a given destination So that I can plan my next trip with Flying High Airlines Feature Acceptance Criteria -Need 2 points per km -Members can calculate points needed on their account home page Acceptance Criteria Automated Acceptance Criteria
  17. 17. Automated Acceptance Criteria Automated Acceptance Tests
  18. 18. Automated Acceptance Tests Applica9on Code Low level specifica9ons
  19. 19. A typical BDD workflow “But what are the deliverables? Meaningful feedback on what requirements have (and have not) been delivered
  20. 20. An incremental approach “But what are the deliverables? Descrip9on of each feature with an example of how it behaves
  21. 21. An incremental approach “But what are the deliverables? …complete with illustra9ons
  22. 22. An incremental approach “But what are the deliverables? How was each feature tested?
  23. 23. An incremental approach “But what are the deliverables? Documenta9on about what you plan to deliver in each release
  24. 24. An incremental approach “But what are the deliverables? Useful low-­‐level technical documenta9on with liRle overhead
  25. 25. An incremental approach “But what are the deliverables? …and targeted automated regression tests
  26. 26. BDD for detailed coding
  27. 27. Business Goal Business Goal Business Goal “building the software right” FFeFeaeatatuturureresess FFeEeaxatatumurrepesless Low level speLcoifiwc aletvioenl s speLcoifiwc alteivoenls specifications Executable specifications We can automate these examples in the form of “executable specifica@ons”
  28. 28. Business Goal Business Goal Business Goal “building the software right” FFeFeaeatatuturureresess FFeEeaxatatumurrepesless Low level speLcoifiwc aletvioenl s speLcoifiwc alteivoenls specifications Executable specifications spock RSpec Low level specifications Low level specifications Low level specifications Low level specifications Low level specifications We use low-­‐level BDD or TDD tools to define the behavior of components, classes etc.
  29. 29. “building the software right” Acceptance criteria tell us what we need to build…
  30. 30. What would we like the API to look like? “building the software right”
  31. 31. “building the software right” Then write low-­‐level specifica@ons for the code
  32. 32. “building the software right” These low level specifica@ons become technical documenta@on for your APIs
  33. 33. What tool should I use?
  34. 34. Collaboration before Automation “Having the conversaDon is more important than recording the conversaDon is more important than automaDng the conversaDon” -­‐ Liz Keogh
  35. 35. Know your audience
  36. 36. DeThmanko You

×