2

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?

  • Can anyone help or advise on my question please?? – Luke Apr 6 '18 at 18:09
1

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.

  • Thanks for the reply @Michael Durant this is the exact approach we have taken and so far so good. I think you have summarised the situation very well, when the technical debt is fulfilled we may look at BDD again but for now we’re happy to continue without. – Luke Aug 5 '18 at 21:16
0

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.

  • Thanks for the reply interesting that product disengage with the process. I guess I’m leaning towards not doing it; particularly for the manual regression tests we are looking to automate first - seems like a needless duplication of effort in this case!! – Luke Apr 7 '18 at 19:55

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.