Introduction
The arguments for the need for agility are many, and you’ve heard them all before... Changing requirements, bridging the gap between business and IT, the pace of change in the outside world is ever increasing, and lead times for releases must be reduced. The hard part however is how to achieve this in practice. A good place to start is by taking inspiration from the methods of Behavior Driven Development, which lend themselves well to implementing automatic testing.
With the help of Behavior Driven Development, the requirements, development and test work is pushed closer together. It consists of writing and building the acceptance tests first, in a way that the business can understand, and the developers can easily automate. This drastically increases the likelihood of building the right things the first time. It also shortens the lead times for a feature to be built, tested, deployed and released. Furthermore, it saves time for the future, since the built-in, automatic tests can even be reused as regression tests when you come to developing new features.
What is Behavior Driven Development?
Behavior Driven Development is a process and approach to software development, whereby business value and the behaviour of the user when interacting with your product is placed in the centre. By providing this common focus for the business and technical teams, communication issues and misunderstandings are avoided, and you can ensure that the software you build meets the requirements, and achieves the desired business goals.
At the heart of Behavior Driven Development is the 3 amigos meeting, which consists of the key trio; business (the customer), a tester and a developer. During the meeting, the goal is to go through the background and purpose of the story, create a common understanding for what should be built, as well as write acceptance tests which describe how the solution should behave. The acceptance tests normally use the gherkin format which is as follows:
Given: Sets the conditions for the test. Here you include what has happened prior to the test starting, including which steps the user has already completed to get to this point.
eg. Given a customer has added an item to their cart and filled in their details at the checkout, including a valid method of payment.
When: This is the trigger for the event being tested, for which we are looking to verify the outcome.
eg. When the user clicks on the "pay" button.
Then: This part states the expected outcome of the test, including enough information to know whether or not the test was passed.
eg. Then the order should be successfully placed and the user should be shown the "Order Placed" page, confirming that it was successful.
How does this fit together with automatic testing?
Automation is crucial for development teams to be able to successfully apply BDD and also to be able to meet the fast-changing market needs and requirements. The way the acceptance tests are written lend themselves well to easy automation, since the pre-conditions, trigger and expected outcome are clearly stated. There are even frameworks which enable the implementation of the tests to be done simply. An example of this is Cucumber, which is open source tool and can be used together with Selenium to automate tests.
The first task for developers after the 3 amigos meeting is to build the first tests. The tests will of course fail since the story hasn´t yet been developed, and they will not pass until the developers have built the story exactly according to set requirements. When the test passes, the feature can be reviewed by the trio again, to verify that the system behaves as intended. If not, more acceptance tests need to be written or the exsting ones modified to ensure that the system behaves as expected.
A long-lasting test automation structure can then be used as regression tests and also be set to run on each deploy. This reduces the amount of manual regressions, saves a lot of time, effort and resources and makes it possible to deploy with shorter cycles. Last but not least, in addition to more efficient development and faster deployment cycles, it also makes the work a lot more fun!
Tips for Success
- Break down the story enough so that the 3 amigos meeting isn’t too long
- Ensure that participants have a good level of understanding of the story prior to the meeting so that you can drill down into the details more quickly
- Choose the participants for each meeting depending on the story being discussed, and include subject matter experts where necessary
- You can write as many "Given" as you wish to ensure that all the conditions for the test are set. However, the "When" should be a single event, with a clear outcome ("Then") so that it is clear what is being tested
- Think carefully which tests should be automated and which need to be manual
- Try including business and testers in mob-programming following a 3 amigos meeting. Even if not all participants have programming ability, time can be saved by having all the diverse, required competences in the room. This works best for stories which include a lot of business questions
If you'd like to discuss this further or share ideas, don't hesitate to get in contact with us at alexander.danson@centigo.se and johanna.svardh@centigo.se, we'll be more than happy to continue the conversation!
Read more:
https://inviqa.com/blog/bdd-guide#what-is-it
https://www.adlibris.com/se/bok/lean-agile-acceptance-test-driven-development-9780321714084
