Business Driven Development
Acceptance Test Driven Development
View more presentations from Naresh Jain
This deck has a couple of visuals that are keeprs! What's more, I really think this style of development / testing is the most important advance in software engineering in a very long time. While I've never fully bought into Uncle Bob Martin style TDD I would however advocate for 100% coverage of User Stories with Acceptance test. When it comes to Unit test I do like non-functional quality measurements to be baked into the business requirements from the start. For legacy apps I'd target ~80% coverage for the most complex and/or the most used pieces of the code base.
I'm usualy not big on semantics but I do think calling this style of development, Business Driven is both the smartest and most accurate description of the process. In the end it is is always the *Business* you have to sell too, so why not give them what they want?! It drags product owners right into the actual development process since they have to write acceptance test. I'm also betting that once they get a taste of that, they'll be hooked and wont be able to stop writing test.
I also like the idea of leveraging the idea that Business and IT *pair program* these test to deliver both business facing and technology facing test. Really pause for a moment and think about that, the Business and IT pair programing, using a Domain Specific Language in a way that ensures they reach a mutual understanding of what is expected! How does it get any beter than that?!
Udate: 2 Jan 2012
Having recently read Specification by Example I have been convinced that the name is important semantics and all