Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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?

share|improve this question
add comment

1 Answer

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!

share|improve this answer
    
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? –  JoeGeeky Dec 8 '11 at 8:01
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.