Specification by Examples
BDD, Acceptance Test Driven Development, 3 Amigos Meetings
Why do we need Specification by Examples?
Many of the expensive bugs are created in the design phase, by assumptions and implicit requirements.
Specification by Examples, if done right, is a very powerful tool which is able to align understanding of the requirements between different stakeholders and prevents many expensive bugs from rising. However, it is also one easily misunderstood practice that people take the tools without understanding the process; therefore found the process clumsy, examples hard to understand, tests brittle.
Common Problems with Software development:
- Block to Continuous Delivery: Long regression tests cycle
- Test cases and feature documentation get out of sync
Agile Development: Shorter iterations and frequent releases. To do so, we want shorter regression test cycle; we want to automate tests; we want to know what features are checked automatically and what require manual attention.
What are the processes involved in Specification by Examples?
3 Amigos workshop: a conversation between SME (Subject Matter Experts), developers and testers on a feature. By including specific examples of the feature, we make sure 1. the terminology is used and interpreted in the same way and 2. the understanding of the capability and boundary of the features are aligned.
What are the tools involved in Specification by Examples?
- Cucumber, Selenium, a programming language (Ruby, Java etc)
Common Myth
- We should automate all tests
- We need to make the examples clear and map each step to one mouse/keyboard action
- We need to capture the requirements in each Jira ticket in the Given/When/Then examples, including UI designs, components present …etc
The answers to the common myths are included in this presentation. This presentation is based on the training material prepared by Richard Paul, the Principal Engineer who introduced Specification by Examples to Orion and helped us writing better scenarios.
Key Points on the Feature Files
- Declarative: Focus on “What” to test, not “How”, so that they are easier to understand
- Express the scenarios in terms of the domain instead of the user interface
- Focus on KEY examples, not all combinations: https://gojko.net/2014/05/05/focus-on-key-examples/
- Avoid Scripts and flows