Generating manual test scripts (in HP ALM) from Cucumber features

[toand...@pivotal.io]

Hi,

There's been some discussion of driving Cucumber from HP ALM before, but i'd like to try something different.

I'm involved with a project which will practice acceptance-test-driven-development, where Cucumber is an option, but where HP ALM will be used to organised a parallel scripted manual testing effort. This company has exclusively used scripted manual testing before, and is keen to continue using it until confidence has been built in automatic testing, which i think is entirely reasonable.

The scripted manual tests should cover much the same ground as the acceptance tests, and vice versa. I can't imagine there will be anything not covered by acceptance tests, as we will be doing test-driven development. It's possible that the manual tests will be less thorough, but i'm prepared to assume not.

Therefore, it seems to me like it would be a good idea to somehow generate the manual test scripts from the acceptance tests; this gives us an easy way to keep the two sets of tests in sync, makes it easier for the existing QA team to give us feedback on the tests, and saves them a lot of effort. This is leading me to prefer Cucumber over a pure JUnit (etc) approach, because it seems like a better starting point for this generation process.

Does this make any sense? Has anyone ever done anything like this? How can i exploit my existing step definitions to write a tool to do this translation? Can i hook into Cucumber's parser somehow?

In particular, has anyone ever created a test lab in HP ALM in this manner?

tom

[Paolo Ambrosio]

Might be crazy but you could use a combination of formatter and glue
code. The formatter would output print feature, scenarios and steps
(perhaps directly in the format used by HP ALM). Your glue code could
add for each step the manual tasks a human would have to do, using a
singleton (or similar pattern) to append those in the formatter's
file(s).

This means of course that you'd have to write both the automation and
manual steps for every step definition. It might be easier if you have
clean abstractions in your step definitions like page objects on a web
application.

[Eric Kessler]

As others have said, converting one test into another will take a good bit of effort on your part due to the 'one to many' relationship of a single, abstract step in gherkin to potentially many discrete step executions by a manual tester. How painful the back and forth conversion will be will depend heavily on how much of a consistent DSL is used by your manual and automated tests. That being said, it is doable. Converting a lot of manual and QTP tests to Cucumber and then identifying the resulting Cucumber scenarios for similar ones that could be further reduced into scenario outlines was one of the first large scale scripting and conversion efforts that I had to do. This encouraged me to come up with a way to simplify interacting with feature files.

This is the fruit of that simplification effort: https://github.com/enkessler/cucumber_analytics

Best of Luck!

Eric