Specification by Example Explained
What if you could write functional tests without writing a single line of application code? What if those tests are written in plain English (so that anybody could understand) but still it's executable spec or source-code? What if you could generate the documentation from live production source code? Now you don't need to update the requirement doc all the time.
What's Specification by Example? Is it different compared to BDD? Who all participate in defining these specifications? Are functional tests and functional specifications same? These are the questions this session tries to answer.
Outline/structure of the Session
- Why we need ATDD
- How to build a shared understanding of the domain using realistic examples(business, QA, developers)
- Difference between “Specifications by Example” and Acceptance Tests
- Common pitfalls with acceptance testing
- Techniques for keeping the specification alive
Agile team members and Product Owners will learn how to write user-stories collaboratively, define acceptance criteria in executable spec in natural language which everybody can understand. Difference between specification and test and how to implement effectively it in your project.
business analysts, testers, developers, product owners, scrum masters, project managers