MarkPearlCoZa
commented
10 years ago Hi Kevin, Wayne, Mark
Thanks for keeping the conversation on ATDD going.
I absolutely agree that it’s such a context specific practice. We’ve tried with varying degrees of success on various projects which have different circumstances. I’ll give you guys an overview of them to give you an idea what I think has worked and what hasn’t.
We have been using SpecFlow for about a year now, with various levels of success.
On a few projects I have written specs and sent them to our main users and tried to go through them together, but I had no luck – for many people these specs read too much like code (no matter how hard I tried to make them read like business rules).
On a project where I was fortunate enough to have a dedicated Business Analyst I went through the concepts with her and she wrote some really good specs with the developer that the developer then took and implemented. This worked incredibly well. It also happened to be a requirement that SpecFlow was particularly suited to.
On a project where we were thinking up the requirements (especially in the security area, since our customer was relying on us there) we tried to use specs to capture them. We liked this as we could refer back to those docs for the rules. However, the specs were very technical and unlikely to ever be looked at by a business person, so we might as well have defined them in the code in unit tests (or mspec tests).
On a project where we are coaching a dev team that has some analysts their analysts have taken to writing specs like a duck to water. However, they do everything the books say they shouldn’t do (the docs read like scripts, for example). They are getting benefit, but I don’t think it’s where it should be.
On projects where I have relatively junior developers I have found that forcing them to write a few SpecFlow scenarios explaining how they understand the requirement they have before they write any code and then going through those with them has been very helpful in helping them think through the various scenarios.
My analysis so far: The main problem with trying to introduce SpecFlow is treating it as a development tool without really understanding how to do Specification By Example and use it as a communication tool. I’ve seen just about every developer we have treat it as a development tool and it just doesn’t work in that capacity. They watch a quick video on SpecFlow and think they can do BDD because they’ve learnt how to create bindings. They then go off and write specs by themselves because that’s a lot easier than collaborating. But as a tool for building software alone it’s cumbersome, complex and lots of work without enough payoff. It’s important that the specs are written collaboratively because it is in the writing of them that the spec is understood – an analyst writing the spec and throwing it over the wall to the developers is not much better than other forms of documentation and prone to just as much misunderstanding.
So far my finding is that unless you can get buy-in from analysts and testers ATDD is not worth it, but if you can get engagement from analysts (or domain experts) and testers it’s fantastic. This is because it’s primarily a communications tool, not a development tool. It’s used to define what to build together between your testers, analysts and developers. I haven’t yet worked out just how to get that buy-in, and I expect it would be different in every situation, but the effort in convincing those team-members would be well worth it.
Based on these findings we continue to pursue it as a practice in areas where we can because the more we practice the better we will get at it and the more benefit we will get.
I highly recommend reading Gojko Adzic’s book, Specification By Example. It’s not tool-focused at all, and he has lots of team case studies where he looks at how teams are doing this and how it’s working.
Any criticisms, observations, etc would be highly welcome.
Regards, Peter Wiles
Hi All
Welcome to the conversation Peter.
My experience is that we introduced BDD as a engineering practice initially. After 3 sprints we found that it was more then that and needs to be communicated as that its agile transformation inside a agile transformation. Everyone has to be thinking about behaviours and discovery, minimal marketable product etc.
Cara did a great job with our analysts in coaching them towards better stories with scenarios. Some thing she stresses is that they are wrong when you start but that's okay because it will get better. Some people get it, some people don't such is life.
Some concerns is that our stories seem to still be thin or not up to quality that allow all the behaviours to be extracted from the. I guess information entropy is low and then when the dev teams unpack them information spikes and can get out of control so scenario creation gets a bit out of hand.
Where we can we try to get some high level acceptance criteria from our BA's in a liz keogh type of format and then the dev's will rewrite the specs in specflow with our whole team and tester reviewing the specs and finding new scenarios as the tasks for the story move to in progress.
Our Dev teams have taken like a duck to water to writing scenarios in spec flow and driving development with specs. This is wonderful seeing our main customer origination application is 7 years old, zero test coverage. We are still finding new ways of attacking problems with the way we are working, and the guys are learning continuously.
Having said that, I do have a new team that will not touch it with a barge pole and will only do TDD. We have also come to a agreement in our tech sessions that BDD and TDD are not mutually exclusive
I am keeping a journal of what is going on here. Hopefully I can share some learnings with the community via a sugsa or spin event.
Cheers Wayne Pringle