Cucumber is a powerful tool that allows easy team integration into the QA process
Do you want to learn how to get your business, product and development team aligned on what your product does? Do you want to follow a process that leaves a living document about what your system actually delivers to its different stakeholders? The most powerful tool I have found to achieve this is Cucumber with what they call Behavior Driven Development (BDD).
With Cucumber there is not any translation between what your business captures in user stories and in how your system is tested and documented. Traditionally there were lots of requirements and then code is developed and tests written but there were translations at each layer that dilutes the initial specification process and leaves some ambiguity between what was asked for and what the tests cover and even what the product does.
With Cucumber you can start by defining the behavior you want your system to support in language anyone can read and understand. You can then directly use those specifications to implement the tests that validate the acceptance criteria. When done consistently and smoothly this is a powerful tool for an organization to understand and maintain a living document around what their system actual does. Without this, the system and the tests will always start to vary and information about key use cases will be lost.
The steps are well described on the main website: cukes.info
What does a typical feature and scenario read like – here is an example:
Feature
In Order to access my personal photos
As a registered user
I want to Login
Scenario Login
Given I am on home page
And I am a registered user
When I click on Login button
And I enter user1 password1
Then I can access a list of my photos
Starting from this specification, you run Cucumber and it will suggest code stubs and help guide you through the process of flushing out your test implementations until your test passes.
In this way you are fully leveraging the work you did to define your use case with acceptance criteria and you have created a living and readable document of what your system does for your customers.
Nothing comes for free. Following this approach does mean you need to spend more time on your user stories up front. But the value of delivering ongoing documentation and an exact mapping to testing is worth it to me as everyone in the company has access to this information in a very understandable format. What do you think? I’m happy to discuss your experiences and feedback.
Some other useful links for additional information are:
- Cucumber Main Site
- Blog: Cucumber: Testing Web Applications With Capybara, Poltergeist and PhantomJS
- Tutorial