A Review of Scripting Techniques Used in Automated Software Testing <s> D. Keyword-Driven Scripting Technique <s> The promise of successful software intensive system test automation has been advertised by test tool vendors for many years. However, those promises have yet to be fulfilled pervasively on government and industry software projects. There are several types of test automation technology available today but the biggest opportunity for a return on investment (ROI) for software maintenance programs is in the test execution (also called "Capture/Playback" category of test technology). Test Automation problems and the ROI opportunities will be identified and discussed. Further, we will describe the cadre of test automation types then focus on the application and results of keyword-based functional/system/regression test automation. <s> BIB001 </s> A Review of Scripting Techniques Used in Automated Software Testing <s> D. Keyword-Driven Scripting Technique <s> The goal of this paper is to explore the use of Keyword driven testing for automated testing of web application. In Keyword driven testing, the functionality of the system-under-test is documented in a table as well as in step by- step instructions for each test. It involves the creation of modular, reusable test components. These components are then assembled into test scripts. These components can be parameterized to make them reusable across various test script. These test scripts can also be divided into various reusable actions. This saves a lot of recording procedure. The Existing tools for this testing uses Html, Xml, Spreadsheet, etc. to maintain the test steps. The test results are analyzed to create test reports. <s> BIB002
Keyword-Driven scripting technique is a very similar to manual test cases. The business functions of the SUT are stored in a tabular format as well as in step-by-step instructions for each test case. Keyword-driven approach separates not only test data for the same test as in data-driven scripts but also special keywords for performing business function in the external file. The tester can create a large number of test scripts simply using predefined keywords. All what the tester needs is just to know what keywords are currently available to be applied on SUT and what is the data that each keyword is expecting. Additional keywords can be added to the list of available programmed set of keywords to enlarge the scope of automation. It is more sophisticated than data-driven technique  . Fewster and Graham  state that the keyword-driven scripting technique is a logical extension of the data-driven scripting technique. A limitation of the datadriven technique is that the detailed steps of what the tests are doing are implemented within the control script itself. Therefore, keyword-driven technique takes out some of the intelligence from the script, put it into the external file with the test data, and leaves the task for reading both steps and data for the control script. Thus, instead of having data file in data-driven, complete test file is needed in keyword driven scripting technique. It doesn't contain test data only but also a complete description of the test case to be automated using a set of keywords to be read and interpreted later on while test case execution. The test file states what the test case will do, not how to do it. www.ijacsa.thesai.org Laukkanen  supposed that in order to execute the tabular automated test cases, there have to be a middle layer that converts the special keywords to the source code that interacts with SUT (the source code that implements the keywords are called "handlers"). The translation of keywords is implemented outside of the control script itself. Now, the control script only reads each keyword in order from the test file and calls corresponding supporting script. In addition, a driver script, which parses the test data and calls the appropriate keyword handlers, is needed. Figure 11 demonstrates these layers. He also divides the keywords into two different levels of test keywords: high level and low-level keywords. Low-level keywords are more suitable for detailed testing on the interface level (e.g. Input, Click, and Select…etc.). High-level keywords are more suitable for testing higher-level functionality like SUT business logic (e.g. Create Account, Login…etc.). Multiple low level keywords can be combined together to form high-level keywords  . Zylberman and Shotten  show that keyword-driven technique is the next generation approach of automation that separates the task of automated test case implementation from the automation infrastructure. They state that keyword driven testing can be divided into two main layers: 1. Infrastructure Layer: It is a combination of the three types of keywords. It receives the different keywords as inputs to perform operations on the SUT. 2. Logical Layer: This layer helps manual testers to build new test scripts using the pre-defined keywords (that is already implemented in Infrastructure Layer). They also divide the keywords into three different kinds (item/base level keywords, utility functions, and sequence/user keywords) which described below  : 1. Item Operation: an action that performs a specific operation on a given GUI element. Parameters should be specified to perform an operation on a GUI item such as name of GUI item, operation to be performed and the values needed. 2. Utility Functions: a script that executes a certain functional operation that is hard or ineffective to implement as a sequence. For example: Run Application, Close Application, Wait X seconds, Retrieve Data from DB,...etc 3. Sequence: a set of keywords that produces a business process such as "create customer" keyword. Sequence keyword is made by combining various items and functions. They also suggest reducing the number of keywords by creating multi-function keywords. For example, "Update_Subscriber_Status" keyword is a better approach than creating two special keywords for "Activate_Subscriber" and "Deactivate_Subscriber"  . Although it can be argued that may be it is more useful not to combine keywords together because this allows using them again in creating another test script. For example, tester can use "Deactivate_Subscriber" keyword in another sequence of keywords (e.g. Delete_Subscriber). Rantanen  suggests a new method for dividing system to multiple user stories. Each user story consists of one or multiple test cases. Each test case is to be mapped to the actual code interacting with the SUT while execution. Every test case contains one or more sentence format keywords. Every sentence format keyword consists of one or more user keywords which written in understandable text (they can be understood without technical skills). A user keyword consists of one or more base keywords. Finally, the base keywords contain the source code interacting with system to be tested. Figure 12 illustrates dividing SUT to multiple user stories. Rashmi and Bajpai BIB002 proposed a new contribution for keyword-driven framework based on the concept of recording as shown in Figure 13 . To start automating process, enter the URL of the system to be tested. Like linear scripting technique, the keyword driven testing framework records the steps while user navigates the web application manually. The 200 | P a g e www.ijacsa.thesai.org user name and password are entered in the appropriate text boxes, and then the user clicks the Log-In button. The tool records all the operations performed manually in the web browser until the test is stopped. When finishing the recording, a corresponding test script file is generated that contains all user actions. The user actions consists of items clicked, items selected and value typed…etc. These steps are generated in tabular format, representing each operation performed in the form of keyword, value and operation. When the test is finished and replayed back, the tool runs keywords that were saved in the output test script file. The SUT opens in a new web browser and all recorded steps are performed again automatically, as it was originally performed manually in the test. After the new test run is completed, the test results are displayed to indicate the status of the test whether the test is passed or failed. The test results window displays two key elements of the test run for analysis purpose. The first one presents the steps that were performed while test execution while the second element presents the test result details. Object Repository is a centralized place for storing the properties of available objects in SUT. Websites are developed using many different objects (e.g. textbox control, input tag). Each object is identified based on the object type. It has properties (e.g. name, title, caption, color, and size) and specific set of methods, which help in object identification. Wissink and Amaro BIB001 state that the principal feature of the keyword-driven scripting technique is the separation of engineering tasks into a set of roles. These roles include test designer, automation engineer, and test executor. To automate test cases in the keyword-driven scripting technique, the next steps are to be followed: 1. A set of actions need to be defined by the test designer and then documented in an external file with other keywords, input data, and expected results. 2. The automation engineer implements the different keywords defined above by the test designer in the programming language of the tool. 3. The test executor just runs the tests directly from the spreadsheet. The advantages of keyword-driven scripting technique mentioned by Linda G. Hayes  are:  Using keyword-driven scripting technique, the tester only needs to know keywords and learn how to use them.  The number of generated scripts required for keyworddriven is dependent of the size of the SUT rather than the number of tests. This means that many more tests can be created without increasing the number of scripts.  Like data-driven scripting technique, the way in which tests are created can be modified to suit the testers rather than the test tool, using the format and tools that the testers are most comfortable with. The disadvantages of keyword-driven scripting technique mentioned by Linda G. Hayes  are:  The costs for development of customized application specific functions (framework) are very high in terms of both time and human resources for technical skills. Such specific framework development can be considered as standalone software development that needs to be tested before using in testing other software.  If the SUT requires more than just a few customized keywords, then testers should learn a high number of keywords.