When should the BDD test scenarios be written? [closed]
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this questionI 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?
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.
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.
if you are looking for BDD (also known as Acceptance Test Driven Development) you might be willing to start writing Acceptance Tests early enough before the Sprint Planning takes place. Some other "more agile" approaches tend to postpone this to the last responsible moment, and I have been coaching a couple of teams where the Acceptance Criteria gets refined over time also during the Sprint.
The "Testers" of the Development Team works closely with the Product Owner during the preparation of the Backlog for the next Sprint (it is called look-ahead) and also during the current sprint, they enrich the acceptance criteria when they see fit in accordance with the PO.
It pretty much depends also on how you do execute those tests... if you are able to automate, than things are much more clear :-) We do make extensive usage of Cucumber or Fitnesse to automate acceptance tests, and as you would do with TDD (without the A) you would try to do that before a commitment takes place, at least at a basic level (you do not need all of them to be defined - remember it shouldn't look like a contract).
The BDD goal is to drive the development of Software from a behavioral perspective, that should give you a pretty clear "way" on how and when to write Acceptance Criteria. I found them very useful in combination with the INVEST checklist for User Stories, and the definition of Ready for you Backlog.
HTH ANdreaT
I hope you mentioned Behavior Driven Development.If i am right, It is a process of interactions with developers, QA and non-technical or business participants. it is also a purpose and benefit of Developers code. You can start scrum scenario while they pre planning.
Estimation and prioritization are not in the part of it.
加载中,请稍侯......
精彩评论