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?
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.
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!