The system we are developing, using .NET, is extremely large, complex, and some modules are poorly written. We have a large user acceptance test team that is aiming for 100% business scenario coverage, which takes about 6 weeks.
Can we use behavior driven development to replace some of the manual tests being done by the test team? How would that information be readable to the test teams so they can be sure it's working? Does BDD replace our integration tests?
Behavior driven development is about more than just automated acceptance tests. For more information on that see the wikipedia page on BDD or check the excellent list resources Liz Keogh has compiled on BDD
Now on topic: You could start automating the acceptance tests using BDD tools for .Net. StoryQ and SpecFlow are examples of BDD tools that support scenario's(acceptance tests) in plain text.
Using such a tool not only makes the scenario's readable for the test team, they can actually write these tests themselves. That should give them confidence the tests are working.
If you could get them to writing these tests for all new features before you start coding them. You're getting one step closer to BDD. This gives you the benefit of having an executable specification. You know when the software meets the acceptance criteria, i.e. you're done. When done the specification becomes an automated regression test.
Probably not all tests can be automated or or are worth automating. Sometimes thing can be automated but if you're not carefull they can turn into a maintenance nightmare.
Even if you can automate all specifications this way, testers still have to do some testing by hand or using other tools. You can't replace testers with automated tests, but you could probably reduce the 6 weeks to a lot less.
It sounds to me as if some effort should be spent on the QA side automating the user acceptance test scripts. If you have a large QA team it should be no problem to allocate a core of 3 or 4 test automation leads (QA's with some coding experience) to begin automating the manual test scripts in some way.
Gradually, they filter that knowledge down to all other QA engineers, who in time become responsible for the automation of the test scripts for their assigned areas. We've taken this approach in our team and it has worked quite well.
