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.

  • Thanks Jimmy. What tool do you use, we have Quick Test Pro here but I'm told that the tests are brittle and therefore we can't automate all that much.
    – TimF
    Nov 7 '11 at 11:17
  • 1
    QuickTest pro is a good tool if it's used correctly. The good thing about it is that it can identify objects (buttons etc.) via a number of properties, if one isn't found, it reverts to the next and so on. We found that getting buy in from development to make the product more automatable was the way to go (e.g. ensuring all controls have static ID's that don't change between builds/minor versions). QTP's record and playback is quite bad, we found that hand writing the tests made them much more maintainable and likely to work in newer versions. Nov 7 '11 at 14:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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