Acceptance tests should be written first, before the code is written. When they pass, you know the feature is complete and does what it is supposed to do. However, most of these tests only follow the happy path. Let's consider two scenarios:
- Your QA department is able to handle writing their own automated tests.
In this case, you've saved them the trouble of writing happy path tests, so they can concentrate on edge cases, mutation testing, stress testing, exploratory testing, and regression testing. Also, they can remove your tests from their own test runs if they prefer to have their own acceptance testing. You've produced code that is less likely to be buggy, saved them time, and allowed them to focus on what they're good at... QA isn't about making sure the software does what it should do--you shouldn't ship code to them if there is any question of that--it's about making sure that the software doesn't do what it isn't supposed to do.
- Your QA department is not able to handle writing their own automated tests.
In this case, you've written automated tests which they can't write, which is helpful. Perhaps they'll learn to read the automated tests and understand what you are testing, which will help them develop a test plan. You've also shipped software that you know works on the happy path, which means that the QA department has more time to focus on exploratory, regression, etc. Their job is to break your software, not verify that you're minimally competent.
In either case, following a behavior driven development plan saves time and money and produces more robust software.