BDD Journey: ATM Cash Withdrawal Scenarios
•Download as PPTX, PDF•
0 likes•398 views
Prezentacja Bartosza Szulca w ramach Quality Meetup #2. O inicjatywie: http://qualityexcites.pl/quality-meetup/archiwalne-spotkania/
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
More from Future Processing
More from Future Processing (20)
Recently uploaded
Recently uploaded (20)
BDD Journey: ATM Cash Withdrawal Scenarios
- 1. BDD the journey @BartSzulc
- 2. ? @BartSzulc
- 3. Story: Account Holder withdraws cash As an Account Holder I want to withdraw cash from an ATM So that I can get money when the bank is closed Scenario 1: Account has sufficient funds Given the account balance is $100 And the card is valid And the machine contains enough money When the Account Holder requests $20 Then the ATM should dispense $20 And the account balance should be $80 And the card should be returned Scenario 2: Account has insufficient funds Given the account balance is $10 And the card is valid And the machine contains enough money When the Account Holder requests $20 Then the ATM should not dispense any money And the ATM should say there are insufficient funds And the account balance should be $20 And the card should be returned Scenario 3: Card has been disabled Given the card is disabled When the Account Holder requests $20 Then the ATM should retain the card And the ATM should say the card has been retained Scenario 4: The ATM has insufficient funds @BartSzulc
- 4. @BartSzulc
- 5. @BartSzulc
- 8. I can be developer! I can use fancy tools! I can build my own superb frameworks! I’m on the hype wagon! @BartSzulc
- 9. so much test automation very Agile Tester, so happy @BartSzulc
- 11. NOPE @BartSzulc
- 12. ?? @BartSzulc
- 13. @BartSzulc
- 14. @BartSzulc
- 15. Is every possible scenario an acceptance scenario? @BartSzulc
- 16. Should I avoid complex scenarios? How detailed should they be? @BartSzulc
- 17. Are acceptance tests the only tests? @BartSzulc
- 18. Is BDD a testing framework you should use for all your tests? @BartSzulc
- 19. Where does the idea of automation come from? BDD? @BartSzulc
- 20. @BartSzulc
- 21. Pivot @BartSzulc
- 22. Interact with business @BartSzulc
- 23. I can be business analyst! I can help refine requirements! I can help understand complexity! @BartSzulc
- 24. so much business understanding very Agile Tester, so happy @BartSzulc
- 26. NOPE @BartSzulc
- 27. ??? @BartSzulc
- 28. Let’s play chinese whispers @BartSzulc
- 29. @BartSzulc
- 31. Interact with developers @BartSzulc
- 32. Developers understand what is needed! Development is driven through examples! Clearly you create solid development team! @BartSzulc
- 33. so much driven work very development team, so productive and lean @BartSzulc
- 35. NOPE @BartSzulc
- 36. ??? @BartSzulc
- 37. Wishful thinking Wasteful requirements @BartSzulc
- 38. @BartSzulc
- 39. Pivot @BartSzulc
- 40. INTERACT WITH EVERYONE! @BartSzulc
- 41. BDD @BartSzulc
- 44. I can help understand what business wants! I can help drive development of the need! I can assure the need is delivered! @BartSzulc
- 45. so much INTERACTION and COMMUNICATION very Agile Tester, so happy @BartSzulc
- 47. YES @BartSzulc
- 48. @BartSzulc
- 49. even More Benefits! @BartSzulc
- 50. @BartSzulc
- 51. @BartSzulc
- 52. Recap @BartSzulc
- 53. Discuss the idea @BartSzulc
- 54. Do the dry-run @BartSzulc
- 56. End
Editor's Notes
- what is bdd? why should you implement bdd in your team?
- here is a simple story and related scenarios there is also option to have features and related scenarios what is feature? this gives a glimpse of who should create a story and help creating scenarios we want to address business need, but it’s so complex...
- so where does such scenario fit into the testing quadrands?
- exactly here look we have 3 more quarters to fill
- so what you do when you start?
- you look into automation tools because you are engineer because you enjoy programming because you enjoy automation because you want to impress developers answer to: do you use BDD? yes, we have cucumber
- so clearly you are the best and you do bdd
- you are on the hype, you are the agile tester, who isn’t really a tester, it’s just a developer in sheep’s clothing
- ok, so is there really a benefit in all of these?
- you’re not developer, you miss knowledge, experience, best practices software still doesn’t meet acceptance criteria features are not accepted by customer, his expectation vary from mine you increase technical debt you are now part of vicious circle, you automate tests, you write bad code, your tests are brittle, you have less time to spend time on testing, quality of your product decreases
- ok, do retrospective, what failed, choose most important thing and try to improve
- this is how your tests should be structurized
- and here is the reality but it’s even worst because you do have acceptance scenarios over UI tests
- so you come up with questions, like do I need to create acceptance scenarios for all test scenarios in my mind? who decides what is accepted and what is not? wait a minute, shouldn’t the acceptance criteria fit on a small card?
- what about how the scenarios should look like? clearly I can use all of the features cucumber, jbehave or behave give? but should I? how should a proper scenario look like? it shouldn’t be too descriptive but should give enough description so it extends acceptance criteria - this is not the case if you’re a technical product owner who works on a library for instance or backend service
- while you spend a lot of time implementing these tests, are these the only tests you could do? what about other quarters from the test quadrant?
- can I do all these other tests without BDD? do I need BDD to do them? is BDD beneficial in any way?
- and why is it so important to use tools in BDD? is it because of BDD or is it because of Agile and quick releases?
- so where am I with BDD looking at bigger picture?
- ok, so you need to try different approach
- clearly business needs to define requirements, I’m here only to help
- started understanding business product owner understands what requirements refinement means and what is it driven by by complexity! I’m an Agile Tester, I understand how things work together, how components are coupled, how they interact, and what is the risk and complexity in implementing new features
- now everything will work as supposed to
- so do we have a software that business wanted?
- nope, not really, no
- so what went wrong?
- product doesn’t meet client expectations… but at least these are mine expectations as well now you have at some point to explain requirements to developers, how is it different than waterfall?
- so you have someone to talk to, but still no progress
- or another variation
- you start interacting with developers
- at least I think so
- n
- you think you understand what is required from you, you don’t you hope it’s what is needed, but it isn’t at the end you create waste, not very lean
- you find yourself at the same spot
- ok, so you need to try different approach
- you need to interact with everyone, not only with yourself, with developers, or business, but with all of them together, be a business-development bridge
- what BDD really means?
- here is a place for business-development-testing integration, find what is expected from you, help understand what are the risks, costs, etc. maybe we don’t need this features? maybe it will not bring expected ROI
- drive your development and testing with the defined behaviour developers need to change the way they implement new software, you’re there to help them understand benefits, coach them
- customer got what he expected, even better, he got everything that brings him profit, we get rid of waste before development starts
- you finally see the whole bridge
- I’m no longer responsible for test automation, developers are I can focus on boundary, edge, system testing, inspecting production, checking usage patterns, that’s what is most interesting test documentation and code in one place, full integration of the development team, no test/dev subteams e2e, acceptance tests, part of the build process, not an unwanted child of building process I know what implemented system does just reading features description and linked acceptance criteria, I don’t need to read poor quality acceptance tests written by testers (selenium ide) or developers (advanced patterns=overengineering)
- I can focus on other aspect of testing in agile
- and we have a lot of these aspects, quadrants focus only on technical, and business partially you don’t have anything mentioned about monitoring production status of your product, validated learning, and so on and you don’t have anything mentioned about delivery processes, continuous integration, delivery, deployment, complex system testing
- what I’d have done differently
- with all parties, not only developers or business
- don’t start from implementing frameworks, evaluating and adopting tools that may help you later with the overhead, start simple forget about tools help understand product owner what is expected from him, how hard it might be for him to describe acceptance scenarios work with developers and drive the development through defined and agreed acceptance criteria, even if you would have to accept dev increases them running manual tests
- improve by adopting tools, frameworks, etc.