Organisation of Acceptance Tests(Specflow/Cucumber)

Question

Now I'm starting to work more and more with BDD techniques(spec flow and Cucumber), I’m starting to think about the organisation of the projects/solutions I create and ensuring that I future proof it in some way.

For example, Sprint 1 starts and we decide to write our acceptance tests using spec flow/c#. As a result we build up a series of feature files which together encompass all the user stories in Sprint 1 and from that point on they can run in an automated fashion. The questions I have are:

1) What happens when sprint 2 starts? Would we just keep adding new feature files and code to the solution we build in Sprint 1, and just create new sub-folders so as to separate the features in each sprint? Or is there an alternative way of doing this…potentially, we could have sub-folders in the solution for each area of our system and we add to the automation suite that way?

2) In terms of naming conventions: a) what is the recommended naming convention for the solution/project, given that over time it could have a huge amount of features within it, each looking at different areas of a system? For features, should the name of these correspond with the user story title or id? b) What’s a good way of being able to refer back to these acceptance tests, say in 6 months? Obviously, a business user wouldn’t want to trawl through Visual Studio projects, so could these acceptance tests be exportable to a html webpage?

Appreciate any advice people may have.

Answer 1

1) After you have completed sprint 1 you should have new version of a component released since all sprints should deliver new version of a product. Also if you have completed sequential sprint, then you should have also completed all the features which felt in scope of your sprint. So, having new sprint means having new features and thus having new feature files.

2) This is subjective thing. This might depend on how complex your product is and what is the structure. There should be some single approach on how to organize feature structure. Nor just for your BDD tests, but for manual tests and for development, for code repos, etc. This will let you easily refer from any tool to any other tool (like having Story in Jira easily map it to the tests in BDD framework)

Regarding getting back to the tests in future there is a conenient mechanisms of test tagging, so you can tag the tests with just a free text (for example you may tag the tests with sprint number, or with feature, or with area) and then scope the old tests by the tags meeting your current needs.