Keyword-driven testing is a functional testing, also called table-driven testing or action-wordbased testing. In this testing, a table format is used, most likely a spreadsheet, to define keywords for a function to be executed.
Basically, it is a scripting technique which uses data files to contain keywords that are related to the software under testing. These keywords represent a set of actions needed to execute a specific step. It includes high-level and low-level keywords, as well as keyword arguments, that is composed to define the action of a test case.
The testing starts by identifying a set of keywords, then associating an action to the keywords. Each testing action such as opening and closing o browser, mouse click, etc. is defined by a keyword, e.g., openbrowser, click, Typtext, etc.
Keyword-driven testing is best suitable for inexperienced or non-technical testers. It allows writing test cases in a more conceptual way using this approach. Moreover, it also enables automation to be started earlier in the SDLC (Software Development Life Cycle), way before a reliable build is delivered for testing. Keyword-based testing has a high degree of reusability.
However, it may take longer initially to develop the keywords and related functionalities. Also, it may put a potential restriction to technically abled testers.
For example, consider a website. The keyword “login” is used in automation framework to test the login function associated with it. Also, the keyword “logout” is used in automation framework to test the logout function related to it.
|Login||Login to “XYZ” website|
|Emails||Send an email|
|Logouts||Logout from “XYZ” website|
|Notifications||Find unread notifications|
Keyword-driven Framework is a framework for automation testing that separates test cases into four parts to separate coding from test cases and test those steps for efficient automation.
It separates the test cases into test steps, objects of test steps, actions on test steps and data for test objects for good understanding.
Function library − It is a JAVA class in which all the keywords are defined. That is, all the actions that are to be executed on the software are defined as user-defined methods in the library class file.
Excel sheet − The user-defined methods and their functionality details are recorded in an excel sheet so that users can understand what keyword the library contains. These sheets are like a summary of the library file and prove useful in creating test case template, where users can look at the keyword list in the sheet and select the respective keyword for an action in the test case.
Test case template − According to the project, the test case template is generated. However, there is no specific rule or standard to create templates. They are created based on how much the project requires the framework to manifest. This manifestation may be just for keywords, or even test data and UI elements are also manifested.
Object repository − UI locator can be found, and its value can be acknowledged in the template or maintained in a different object repository.
Driver/Test script − It is the primary script that reads the excel sheet and executes the respective action. It is designed according to how the template is created.
Excel Sheet − Identify keywords and record them in an Excel sheet.
Function Library − It includes function for business flows. When a test case is executed, it reads the keyword from the sheet and accordingly calls the functions.
Data sheets − They are used to store test data, to be used in the application.
Object repository − Based on the keyword-driven framework, select an object repository.
Test scripts − According to framework’s design, create test scripts for each manual test case, or one driver script.
Common components managed by the standard library.
Helps writes tests in a more conceptual way.
Script details are hidden from the user.
No need of scripting languages.
Concise, maintainable and flexible testing.
Keyword-driven testing can be performed, both manually and automated. However, commonly it is done with automated testing.
Purpose of automating keyword-based testing
Reduces maintenance cost.
Avoids redundant specifications.
Reuse of function scripts.
Excellent portability and testing support.
To execute more testing with same or lesser effort.
With keyword-driven testing, in the earlier stages of development, easy functional tests can be created, to test the software piece-by-piece. An easy way to compose keyword-driven testing is to record it. Then, the test can be customized based on the requirements. Each keyword should be associated with at least one command, that can carry out the actions associated with that keyword. After all the test cases have been executed, a test library; called by a test automation framework; interprets the keywords.
Keyword-driven testing can be summarized in the following steps −
Identify low- and high-level keywords.
Implement the keywords.
Create test cases.
Create driver scripts.
Execute automation test scripts.
HP QTP − This is an automated tool for functional testing, that enables executing automated tests to detect errors, defects or gaps, opposite to the estimated results of the software under testing. It was developed by Mercury Interactive. Later on, HP acquired it, and currently MicroFocus owns QTP. QTP (Quick Test Professional) is also known as UFT (Unified Functional Testing). QTP/UFT is an icon-based tool, that enables automating regression testing and functional testing of softwares. This tool is easy to use for both technical and nontechnical testers. It offers Record as well as Playback features and can be used for desktop as well as web-based applications. QTP/UFT also enables Business Process Testing (BPT). This tool is basically based on scripting language VB script. UFT uses VBscript for automating applications and supports a massive pool of software development environments, such as SAP, Oracle, and so on. It helps testers perform automated functional testing without any interruptions.
Selenium − This is an open-source tool used to authenticate web applications across different browsers and platforms. Selenium Test Scripts can be created using various programming languages such as PHP, Perl, Ruby, Java, C#, Python, etc. Usually, testing with the use of Selenium testing tool is referred to as Selenium. It is a suite of software, with each piece serving different Selenium QA testing needs. The tools include: Selenium IDE (Integrated Development Environment), Selenium RC (remote Control), WebDriver, and Selenium Grid. Selenium RC and WebDriver are integrated to one framework to form Selenium 2. Selenium 1 is Selenium RC.
|Supports different browsers||Supports only Firefox, Internet Explorer, and Chrome|
|Supports different operating systems||Supports only Windows|
|Supports mobile devices||Supports mobile app test automation by using HP Mobile Centre|
|Can perform tests even when browser is minimized||Needs the software to be visible on the desktop|
|Can execute parallel tests||Can execute parallel tests, but using a paid product- Quality Centre|
QTP can test web and desktop apps, unlike Selenium that can only test web apps.
QTP includes a built-in object repository, while Selenium does not.
QTP automates faster because it is a full featured IDE. While, Selenium automates slowly as it has only third-party IDE for development.
QTP can access controls within the browser, while Selenium cannot access elements outside of the software under testing.
QTP, unlike Selenium, offers professional customer support.
QTP has innate capability to export test data into external formats.
QTP automatically creates test reports.
QTP includes built-in parameterization support.
Even though, QTP has so many advantages over Selenium, yet the latter surpasses the former in following −
It enables functional testers plan test automation even when the application is not ready. Moreover, once the framework is established, manual as well as technical testers can easily create test scripts for automation.
This testing is maintained and recorded in an excel sheet and no code is exposed, thus making the test scripts easy to read and understand. The keywords and actions so perfectly resemble the test cases that it becomes much easier to write and maintain.
Even before the software is delivered, testers can start creating keyword-driven test cases, because object repository can be easily established later on. Using documentations or information collected from other requirements, keyword data tables can be built that respective manual test procedures.
With the help of modularization, keyword-driven testing offers and further increases reusability. Because there is a single driver/test script, it strongly encourages code reusability.
Test cases can be generated even without any programming knowledge.
Keyword-driven testing does not depend on any particular programming language or tool.
It supports all the automation tools.
TC_01 − Login to “XYZ” website, determine the number of transactions executed today.
TC_02 − Login to “XYZ” website, send an email to one of the clients, then logout.
TC_03 − Login to “XYZ” website, find received notifications, if any.
Keyword-driven testing is a scripting technique, using data files to store keywords associated with the software under test. Usually, it is performed by automation testing. Test cases can be created even without any programming knowledge, and the test supports all the automation tools.