The basic idea behind the keyword-driven testing approach in test automation is to separate the automation from the test case design. This is usually achieved by using an additional layer of abstraction where the tests itself are defined technology-independent and readable for non-technical personnel as well. Thus, a keyword could be defined as a set of actions performing a “Login” or “Save”-Operation.
Based on the technology-independency, tests might be developed earlier in the QA process and beneficially they are easier to maintain for that reason. Next to that, labor can be divided easier based on different levels of technical experience. Here the automation (keyword implementation) can be done by technically experienced team members whereas the test case design (keyword usage) can be done by domain testers who don’t need to have technical skills to that extent.
This blog post describes how the keyword driven testing approach in test automation can be followed within Ranorex, granulated on two different levels.
- Option 1: Keyword-Driven Framework with Automation Modules
This approach can be followed without writing any line of code. - Option 2: Keyword-Driven Framework using the Action Table
Following this more advanced approach, it’s recommended to have at least basic programming knowledge.
Keyword-Driven Framework with Automation Modules
First of all, we will use Ranorex Modules as abstraction layer for the elementary actions performed. Having the modules “StartSUT”, “Login” and “CloseSUT”, someone could easily define a test case without having a clear understanding, how this is technically accomplished in background.
Replacing the term “module” with “keyword” points out that the test case design could be strictly separated from the Automation. Therefore it could be carried out by different people with different levels of technical and domain-depending understanding.
That’s keyword-driven test automation.
Separation in Several Projects
It is recommended to pack your keywords (aka Ranorex Modules) in separate projects, referenced by one Ranorex Solution. Here, the keyword implementation is completely separated from the test case design and keyword usage.
Depending on the level of abstraction you’d like to have here, you can either reference a Ranorex Module Library Project or directly reference the resulting DLL file. More information on that can be found in the blog post “Organize a Test Automation Project with Ranorex“. In the second option, it’s not even possible to open or modify any given module, whereas changes in the modules can be done directly in the first option.
Combination with External Data
To be even more flexible you can use variables inside the modules. This brings up the possibility of letting external data drive your test case as well. Meaningful data placed in an excel spreadsheet, for instance, could define the credentials to login as well as the set of data to be added in a test case. For more information about data-driven testing, please refer the section “Data-Driven Testing” in our user guide. It seems like there’s no limitation to data-drive keyword-driven test cases with Ranorex.
Keyword-Driven Framework using the Action Table
Many people prefer defining test cases in an Excel-spreadsheet-like table since they are used to work like this since years. With Ranorex, it’s possible to implement test cases based on keywords in a table-like workplace as well, namely in the Ranorex Recorder. To access predefined keywords within that view, first a trick has to be done: Inheritance.
Assuming a technical team is providing a bunch of code-based keywords in a code module, let’s say “StartSUT”, “Login” and “CloseSUT”.
A recording module, inherited from this code module, automatically derives all the functionality from the parent module directly accessible within the Ranorex Recorder, even with Parameters as described in the section “User Code Actions and Parameters” in our user guide.
This can be achieved with inheritance in the recording modules “UserCode.cs” file:
After doing so, you simply can add a user code action (Add New Action -> User Code) and choose one of the predefined keywords and, if defined, set the arguments.
You can also follow the data-driven approach within the action table (as already explained in the previous section) by simply making the keyword parameters variable.
That does the trick.
Conclusion
Using Ranorex there are no limitations in following the keyword-driven approach. According to your preferences you can either use the Ranorex Test Suite or the Ranorex Recorder as base of your work. Using the Ranorex Test Suite, the keywords are presented by recording- and code-modules. In contrast, using the Ranorex Recorder with its action table, the keywords are presented by predefined methods held by the inheriting code module.
