"Behaviour is a more useful word than test" - Dan North
As a test engineer, part of my job is to ensure that software functionality, design, performance and other areas of the systems adhere to client or management requirements and that the system is working as it should without any major or critical issues before and after the Go Live date. But more often than not I find that my tests don't always match up to a developers' code, which can get pretty annoying because either I have to go back and change my scripts accordingly or developers have to go re-factor code to match the specification. So this could mean a possible 3 things:
- Testers haven't understood the requirements
- Developers haven't understood the requirements
- Testers and Developers haven't understood the requirements
So how can this be improved? Behaviour Driven Development (BDD). BDD is an agile software development technique which encourages collaboration with developers, testers and stakeholders to understand exactly what the behaviour of a system SHOULD do and not what they THINK it should do. You may say "obviously you would collaborate, isn't that what planning is?" Well, no, not quite. When we sit in a planning meeting, we aim to understand what the outcome of the new feature, story and sprint will be, however do we actually, think about it from a users point of view? What I mean by this is, what is the user actually doing in terms of the behaviour of the system? Let's look at this from an acceptance criteria point of view. Let's say we have an online feedback form and we have the following acceptance criteria:
- The online form must submit the user entered details and on submit display a thank you message to the user.
- The online form must show an error message if a user submits the form without filling in all the mandatory fields.
- The user must be redirected to the home page is they click on the company logo.
Great! so we know what the layout should look like and what features should be present. But what happens when you click on that submit button? What happens if I don't fill in the mandatory fields? What's the behaviour? If this isn't defined, then how can we assume that what is potentially developed is actually what the stakeholder wanted?
Now, let's think about this, of course you could say "well surely you would think about the above tests and write manual scripts for them...right?". I would say "BORING! *yawns*". Then you could say "okay, well then just automate the tests using something like Selenium scripting", I would say, "okay cool, that would work, but hold on, do you really think that a Product Owner wants to read lines of code comments to understand what the user is doing?". You then say "why would the Product Owner care what scripts are being written? Surely all he wants to see is the product working?" I would turn around and say WRONG! <<Enter BDD!>>
Remember what the first point of the Agile Manifesto reads? "Individuals and Interactions over processes and tools". So why would you think that your Product Owner would have no interest in user interactions and the behaviour of the system? Surely this would encourage him or her, to have more say and drive the team to build the right product.
This is the beauty of BDD. BDD uses the concept of specification by example and allows testers to simply think about what the system should do and write this out in the form of scenarios. Let's take the following scenario where we want our user to fill in and submit and online form in simple English phrases:
Given I am logged into giveyourfeedback.com
When I enter my name and telephone number
And I click on the submit button
Then my form is submitted
And I get a thank you message on the screen
Simple! In plain English, you have just described the behaviour of the system/user journey in 5 lines. Easy huh? Now, let's think about this for a second. Your sprint has started, you have started writing your scenarios, and logically speaking, if you run your tests they will fail...right? Perfect! This is the whole point! You start the sprint off by writing failing tests, because if you think about it, the new features have not been developed into the system yet! So after a day or two, the first feature is developed and you start to run your scenarios, they should all pass...IF the developers have developed the right feature. I can see the clogs moving in your brain and you're thinking "yea, but your tests could be wrong too - why do you assume that the developers have developed the feature incorrectly." Well this is why BDD is great and why the Product Owner should have that interest with how the user interacts with the system. The Product Owner should be the person who collaborates with you to understand, write and shape the scenarios, and this is how you know that your scenarios/tests which describes the specification of what the feature or system SHOULD do is correct. Through this process a lot of unknowns, misunderstandings and user experiences problems are resolved.
Okay, now let's take a step back and think about how this all fits into the framework itself. For each phrase, a line, 2 lines or however many lines of code will be written which will sit behind each phrase. The code for each phrase along with other coded parts of the framework which could be frameworks such as Jbehave, Cucumber, Behat (there are so many - dependent on your coding language), will allow the test to run and for the automation process to work.
But this next bit is my favourite part out of the whole framework and concept! After writing 1 scenario, 2 scenarios, 5 scenarios, 10 scenarios, you will see you start to build up a kind of library of phrases which all have code sitting behind them ready to be re-used! So you could essentially start writing a bunch of scenarios for your first story within a matter of an hour and it allows the you as a tester to really think about what you are testing and set the specification and how to test the feature or system in the mind of a simple user scenarios, instead of sitting and writing 21 steps for one manual test.
After almost two years of practicing BDD, not only has it worked and it has worked VERY well, it's quicker, more effective, get's developers thinking about what the system SHOULD do, and allows the development teams to deliver the right software through Specification by Example.