Why Keyword Driven Test Automation is not way forward for Agile – 3

Thank you for spending time reading my views on conventional Keyword driven test automation in my first and second articles. I had discussed in detail the issues I see with the conventional Keyword driven approaches in an Agile environment

This is the last article in the series where I give my conclusion on what I see is the most optimal approach for test automation in Agile environment.

As discussed in the previous article, the quickest way to generate test scripts is to use action level keywords, but the test scripts created with that approach do not give insight into what feature is being tested.

The best way to test each feature in an application is by defining the acceptance criteria for the feature. Scenarios can then be created out of these acceptance criteria which can be used by the manual testers to test the application. The more detailed a scenario is, the lesser the assumptions when testing.

The test automation framework that would work well in an agile environment would be the one that combines the action level keywords with the acceptance test scenarios defined by the manual team or business analysts.

There are some frameworks which enable BDD development, frameworks such as Cucumber, JBehave and other similar ones. These frameworks provide you a way to define your tests/acceptance criteria in English like language and implement calls to your own APIs/tools(such as Selenium, Watir). These frameworks may be a good starting point for agile automation frameworks, to allow testers/business users to define their acceptance criteria which can be used to test their applications manually and later evolve them into automated tests.

Using such frameworks(or something similar) can provide two advantages:

• Acceptance tests for each user story – providing full traceability(to both manual tests and automated tests)
• Same acceptance tests evolving as automated tests – The same tests can be implemented at web service/API level or at UI level based on what phase the development is in

The key to accelerate automation with this approach is to have action level keywords implemented for the APIs/tools you choose to use and then use them to quickly build your automation implementation(sometimes even before your application is built), thus enabling a Shift Left approach to test automation and also at the same time having tests ready to use for manual/functional testing while automated implementation is not complete.

It is important however not to get carried away and use the frameworks like Cucumber with English like steps for action level keywords(for example never use a step like “When I click on <abc> button”). If this approach is taken, again it is similar to Action based keyword framework – and your acceptance tests will not make sense(even though written in English).

The acceptance tests should always represent the functionality/scenario being tested, and the automation implementation can use/reuse the action level keyword implementations.

As some of the people have mentioned in comments they have taken an approach to drive automated tests using image based tools, all such approaches can be combined(instead of action based keywords) and implemented with the English like acceptance tests so that it gives an understanding of what is being tested and any changes in user stories – will essentially can be tracked to your manual/functional tests and automated tests.

Thank you for spending time reading my views, although there are some enhancements to be done to existing frameworks like Cucumber to make them work well with any agile test automation, the future is bright. I would love to hear your views, please feel free to comment. Please keep an eye on my posts, as I write my views on more areas around automation and latest technologies.