Putting the Cart before the HorseFrom a Scrum point of view, I think of a story as a placeholder for a conversation. If we can agree with that as a good enough definition, then we can see behavior-driven development or acceptance test–driven development as a framework to help teams have that conversation.
The general idea is that during the conversation, the cross-functional Scrum team, including the ScrumMaster, product owner, and the technical staff, gains some sort of shared understanding of what the story is supposed to produce. The BDD specifications (notice I didn't say test cases) become examples: testable artifacts that are the result of the shared understanding. The fact that these specifications are testable lends them to being treated as test cases, for better or for worse. It doesn't help the case much that often these development frameworks are lumped into a category called "test-first approaches."
Now that we have these testable things, if they are written down, can't we parse them and automate everything? Absolutely. Thus, you have BDD tools such as Cucumber, SpecFlow, and Fit/FitNesse.
The biggest flaw I see in all of this is people saying things like, "Oh, yeah, we're doing BDD, so we're going to use Cucumber." The fact that we can specify the conversation results (i.e., the BDD specifications) in a way that can be parsed, and that we have additional software to check the product against the specifications, is thought of as merely interesting—it’s a bonus, a convenience, that we can do that checking via a machine. The result of the conversations is not automation. The result is a shared understanding of the stories; the specifications are the artifacts of that shared understanding.
Here's the dirty little secret: The automation is not the hard part; the changing of your whole cross-functional team to be "test-first" is. Most teams aren't set up for this. Here are some common problems:
Developers don't want to wait until there are test cases written before writing any codeTesters are not used to being at the front of the pack, so it takes time for them to acclimate to that roleProduct owners, product managers, and other assorted business people are not as available as they should be, so they can't or don't participate in the conversation as much as is required
This change in mindset is the hard stuff.
If you want to take a BDD approach, do just that: Work on getting the approach right, and forget about the automation. If you can't get the approach and corresponding culture right, BDD will fail, either partially or completely.
For BDD, the conversations are the foundation; we need them in order to even come close to building the correct thing. Once they are in place, then we can talk about the bonus that is automated checking of the specifications.
|
