Menu
I am looking into BDD testing within a scrum scenario and realise that the BDD scenarios are more akin to specifications than tests.
Therefore should they be written before the developers go into pre-planning so that all of the functionality has been identified which would allow better estimating, prioritisation etc in that meeting?
992
A BDD scenario is a written description of your product's behavior from one or more users' perspectives. Scenarios are designed to reduce the cost of translation and make it easier for your engineers to understand the requirements and for your QA (if you have one) to test it properly.
BDD scenarios describe test cases in a plain-text form, and though they use Gherkin keywords, they can be created by non-technical-savvy employees. Quite often, they are written by product managers or subject matter experts, and are automated by the QA team or special automation engineers.
The BDD process moves through three phases—discovery, formulation, and automation—where the acceptance criteria are transformed into acceptance tests that are later automated.
If by BDD you mean "Behaviour Driven Development", then you are perhaps being tripped up by putting the word 'tests' in there.
They are not tests, even though you will get free tests out of them. If you think of them as tests, you will use them badly.
They are specifications. If you approach them that way, you can see how they fit into your process.
It's up to you, but you will get the greatest benefit by forcing yourself away from thinking of them as tests, and instead being consistent about treating them as specifications. Nothing can stop you from misusing them (as tests), but misusing them will guarantee you don't get the benefit of the approach - and it's substantial.
153
Generally, in Scrum you want user stories that also have conditions of satisfaction to go along with them. Meaning, that if these conditions are met, I as a Product Owner, will be satisfied that the story is complete.
It's best to have these written by the Product Owner and even better if they are written in the Given/When/Then format. That way the team can create the BDD tests based on the conditions of satisfaction. When the tests pass, the story is complete.
There should be as many conditions of satisfaction as the Product Owner feels necessary to confirm that the story has been implemented and these conditions should be prepared in time for the sprint planning meeting. They don't need to be coded, but they should be written out so that the team has an idea of what is expected to complete the story.
The team may add their own BDD tests during the sprint as things come up, but the story isn't complete until the initial BDD tests pass.
28
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
