We are starting to automate our manual regression suites using Selenium Webdriver and NUnit. The tests we will be automating are quite detailed in terms of steps and expected results however I was thinking of potentially using something like SpecFlow and taking the BDD approach.
Firstly how much value would this add when the manual test cases already exist?
Secondly has anyone had experience of SpecFlow or BDD automation - positive or negative?
In your case I don't think BDD (or its cousin TDD) is necessarily the right tool for what you are doing.
Rather than developing application code based on desired behavior as captured in tests, it sound like you already have the application code and want to address the technical debt of not having test coverage for it, i.e. technical debt - missing tests.
So I would consider 'dropping down a level' and using a test framework at a lower level. For .NET this would be NUnit. I believe this would let you move a lot faster, with less overhead, to gain that coverage that you desire.
The tough part here is, as you move from tackling debt to testing new changes as they are made, you may want to use BDD and TDD techniques. Personally I still say wait until then to start writing them. Find ways to leverage what you are have already written in NUnit at that point. After all you'll have made a good step for 'documentation as code' with them so it should be much easier to do that, compared to the manual setup you have now.
BDD is good in theory. It provides a common language for automation engineers, product and business to communicate. It also can be used as documentation which is always kept up to date. And it can be used to speed up on-boarding new members of the team.
However, I have never gotten the business or product to actually buy into BDD for more than a few months. They eventually abandon it or fail to participate enough or help write the specifications. This leaves the QA team maintaining an extra level of overhead by mapping the automation code to the english like syntax of BDD.
So, it's good to maintain documentation of your system and help train new members of your team. It doesn't really do a good job of engaging non-QA members of your organization in software quality.
