Behavior Driven Development (BDD) approaches such as NSpec seem to bring developers and those that define business specifications closer together. But this has left me trying to figure out how more formal QA-shops incorporate these types of practices into QA-planning, etc... Is this really more appropriate for smaller shops where no formal QA exists, or is there a way to reasonably blend this into larger scenario's?
2 Answers
I could be off my footing here (and if I am, please let me know!), but from a QA perspective, everything that TDD is for automated tests, BDD is for manual tests. Now some of these 'manual tests' may indeed be automated, but only insofar as they're pretending to be a user. They aren't like unit tests.
Just because you have dedicated people doing the testing doesn't make it any less prudent for the tests to be designed before the code is written.
The larger scenarios you mentioned are probably even more streamlined - by having the BDD documentation upfront, you end up with much more material to submit for SOX compliance, which your larger companies require for a number of things, mostly public trading and capital loans.
- Smoother for developers? Check!
- Smoother for QA? Check!
- Smoother for SOX? Check!
Definitely not just for smaller shops with no formal QA teams.
I don't even see where blending needs to occur. The 'behaviors' (which are perfect templates for a manual test document) need to be defined some time. BDD says they're going to be done before the code. I suspect this is because most shops write the code and then write behavior documents (and off of those, test plans) that say what the application does.
Assuming you have these documents at some point anyway, which a shop with a formal QA department would have, BDD doesn't change WHAT gets written - it just changes WHEN it gets written.
Again if my understanding of the problem domain is off, please let me know, as I'm here to learn as much as anything!
-
Thanks for the feedback; I guess I should have been clearer. In this case, I'm thinking about automated BDD processes driven by such things as NSpec or Cucumber. As I understand it, the notion is that business users build their own tests. Although not a bad idea from the perspective of having shared responsibility in clarifying expectations, how then do we reconcile more traditional QA interactions with this pattern? Couldn't this put the business at odds with QA, especially when determining how much testing is adequate to assess a products readiness for production?– JoeGeekyCommented Dec 8, 2011 at 8:01
I use BDD Frameworks commonly as QA Automation using Cucumber4JVM and Specflow.
If your developers are writing the automation framework and your business is writing out the specs than that is amazing for you. I would start by reviewing over the Specs with the business, try and make certain that as many (reasonable) specs are covered. I would also review over the automation suite that the Developers are building to ensure that they are implemented correctly. I have often times had false passes and false fails in my Automated Tests, especially when using BDD frameworks.
This leaves the QA to do more of the discovery/unscripted/negative testing. These are typically far more difficult to automate out and usually will be brittle at best if they do. Personally, I like to write my test cases in a BDD format for these tests as well in case there would be a high ROI if converted to Automated.
Essentially, all of this leads to a better quality software with clearer, more defined requirements from the users. It's a massive win for everyone in my eyes if it is being utilized correctly.
