Recently I heard the term Key-Word Driven Framework from many testing people. Even people are showing interest to know about it and to implement it. Sometimes people are saying unknowingly as Keyboard Driven Framework.
Few months back, I have implemented Keyword Driven framework in one of our projects. We are using Silktest and data files are kept in XML format. The other automation team members also impressed with this kind of implementation. I found this article Automated Testing Institute - Building A Keyword Driver Script In 4 Steps useful to the professionals, who wants to implement KeyWord Driven framework.
After that the expectation goes to implement KeyWord Driven Framework to all automation projects. I am not against to Keyword Driven Framework. It can be used for many projects. But it is not the only one solution for all our automation issues or dependencies. For example, chart automation. For charts, verification will be different and It is difficult to generalize. May be Flex charts can be used if tools are able to identify all parts of charts. One more is unlimited Keywords. Assume that one project contains more than 500 keywords and the automation guys should know the functionality for all those words. It is definitely issue, if number of keywords increased beyond the limit. Currently I'm thinking the scenarios, where KeyWord or Table Driven Automation frameworks can not be used or should be avoided. Below I have listed the cases.
- More Context based Menus
The menu items are shown based on the screen and object. - Multiple Application interactions in single project
- Total Keywords beyond 200
Testers should memorize all keywords. It is similar to remember Differential Calculus and Integral Calculus functions. One should remember keywords for action and verification for all set of objects. - Many hierarchies for Object identification.
It can be solved if testing tool supports X-path for object identification. - Complex data.
One of my projects required minimum 40 string data to create a report and it is just a first step for any test case. Also the data may change in the future. More than 1000 cases required like that. I can generalize the inputs data and it is difficult to maintain and modify the data.
To know the automation framework concepts, you can go through following links.
Test Automation White Papers
My Thoughts about Automation
What is an Automation Framework - from Dhanasekar's blog
Wikipedia - Test Automation
Wikipedia - KeyWord Driven Testing
5 comments:
how do you create a keyword driven framework when there are a lot of html tables where we have to iterate through the table and click on a cell. How can this be keyword driven?
That's what I have given as fourth point.
Assume that you have keyword driven framework already in place and want to use that specific case. Also your tool does not support X-Path for object identification.
Case 1:
Try to keep to use the entire object hierarchy. It is difficult to manage, if AUT table structure changes often.
Case 2:
Use one global variable for that table object if AUT has limited table objects like that.
Case 3:
Create a keyword specific to that table or any table. Here the tool built-in functions will make a difference. You can write your own function to retrieve the particular table object.
Hope that the above cases helps you.
Huge number of keywords can be handled by well documenting the keywords.One good approach is to document you keywords at object level.So when a tester for example sees a text box,on looking at textbox document he will get to know all keywords of that object.Even if Same keyword in one object is used in different object,still it should be documented at both the places.This will be useful for someone at later stage who writes the testcase and not having much knowledge on the underlying framework.
--Dhanasekar S
Dhana,
You are right. Documentation is vital for Key-Word Driven framework. For example, textbox can be available for different type of technologies. In Java, DotNet, Web, Flex and VB applications, textbox will have different class name and few built-in method may not work at times.
Textbox is very simple case. In enterprise application, you may have set of keywords specific to product. Maintenance and training will be cumbersome, if keywords count is growing to high.
Hope you can think through more in this direction.
I store my keywords in to the relevant pages.
E.g: Login page related keywords are stored into Login class.
Account page related keywords are stored into Accounts class.
Post a Comment