In most development efforts, the features and capabilities defined will come from the stakeholder(s) who are sponsoring the development — if not yourself. The stakeholders will interact with someone technically proficient, who will be the decider of what gets scheduled, prioritized, designed, and implemented. Often this person takes the role of a Product Owner/Manager.
Since one of the main focuses in a Product Owner’s day-to-day is understanding requirements and making sure features are delivered as expected — bug free — they will often need a window to judge if this is the case. One way this can be done is writing up a Specification document for a feature and working with a test team to ensure a Test Plan with appropriate Test Cases are created. At that point the Product Owner can decide if sufficient cases and coverage have been accounted for.
This approach is nice if resources have been dedicated to ensuring each test case gets run and can report on the statuses, both while developing a new feature, and during regression. In theory it is nice but not easy to keep in lockstep.
Behavior-Driven Development (BDD) to the rescue!
An alternative approach that also allows Product Owners to understand the extent of feature developed, and their effort to synchronize with a test team is to utilize BDD (A form of TDD that focuses on UAT (User acceptance testing)). In this context, User Stories are created by the Product Owner by way of working with stakeholders and put into a backlog of stories. Each, scenario describes a specific thing that a user would do. These would be descriptive and accurate. For example in a Auction Website platform you may have a scenario:
As an existing member to the U-Sell-It Auction Site when I bid on a product that already has bids and my bid is lower than prior bids, then a message is displayed that my bid amount is too low
As you can see, this is very clear to a Product Owner, and nearly anyone who is looking at the scenario! Also, when products features / capabilities are framed in this way, it helps to identify potential gaps.
How will test use this?
In a testing effort, many BDD frameworks can be used such as Cucumber, and JBehave. At first, adding another DSL to a project may seem like overhead — especially if testing is performed by a team with “test” expertise — and that is a common complaint among many would-be-adopters of using a BDD framework. Though, the value gained from using it outweighs the value of not…
Benefits:
- “Transparency” in the tests created. Tests can be shared with anyone and are highly understandable (it is still possible to map the DSL to badly designed & inaccurate code…)
- Logs. Much more readable and can be easy to identify the step of failure.
- Separation of concerns. Anyone can create new tests, edit existing ones at a high level.
- May help drive better design decisions when creating the code used by the DSL (making generic & more reusable).
Drawbacks:
- BDD framework needs to be learned.
- Custom code may be required to interact with the DSL (previously available out-of-the-box when used without the framework).
- Another dependency.
- New layer to the existing test project + more code.
For these reasons among others, a BDD framework can be a very effective component to add in your development life-cycle.