Software Testing Artifacts – Detailed Guide

4. Test Script

What is Test Script?

img 617dd4e96d22c

Test script is defined as a set of instructions written in human (manual) or scripting/programming (automated) language to verify that the system under test performs as expected.

It is a part of a test case that can have multiple test scripts. 

A test execution engine, along with a repository of test scripts are called test harness.

A single test case can have multiple test scripts when:

  • Test Cases can be manual and by using automated scripts.
  • Each test script provides a different test scenario to test the test case.

A test script code will typically perform the following one or two times:

  1. Identify input elements from the UI
  2. Navigate to the UI component and wait and verify the input elements that show up.
  3. User input simulation.
  4. Output elements identification
  5. Wait and verify the output elements to display the result.
  6. Read the output element result.
  7. The assertion of output value equal to the expected value.

Test Script language with example

Automated testing can be done using the following languages:

Some test automation tools or frameworks having their scripting language can generate test scripts without actual coding. 

Example: Sikuli, which is a GUI automated tool, uses Python to test the test cases. For instance, the following is an example of a test script in Python:

def demo_script (self):
type ("ABCD")
click (ImageButtonX)
assertExist (ImageResultX)

Example of a test script

Let us consider automatic testing for the add function in an e-commerce website. The test script for the website will perform the following:

  1. Specify how to locate the “Add Product to Cart” button from the cart page. Eg. using the CSS element IDs.
  2. Load the website home page, click the Cart icon, verify that the cart page appears, and show the “cart is empty” screen.
  3. Search any item from the product catalog. E.g., Add a dress. Then press “Add to cart.”
  4. Specify how the item added to the cart will be displayed to the user.
  5. Wait and verify if the item is added successfully with adequate details visible on the cart screen.
  6. Read the cart page.
  7. Assert that the name of the product and its details are visible

What kind of code is used?

The kind of coding to create a test script can be of the following three types:


There is no need to write code if the user actions are recorded, and the script is generated automatically.

However, since the script is automatically created, the creator might often need to check the script to fine-tune the automation behavior or fix things.

Nevertheless, this is simpler than writing the script from scratch as the script is right in front of the tester and is generally coded in simplified languages like VBScript.

A “Real” programming language code

Even if the tester might have the ability to record/playback the code or generate simple scripting code, testers might ultimately need to learn how to code on their own.

Testers can choose any programming language irrespective of the programming language used for writing the software. For instance, even if the program is written in java, but the tester is fluent in Python, they can write the Python test script.

Keyword/Data-driven Scripting

The testers, unaware of the underlying code, usually define the tests with the help of keywords. On the other hand, developers implement the test script code for the keywords and update them.

This method is useful for testers but is highly reliant on developing resources for new functionalities to test automatically.

How to Create a Test Script?

There are three ways to create a test script:

1. Record/Playback

For beginners, tools like HP Quick Test Professional can help QA professionals create automated test scripts.

These tools perform a set of actions on a website or application, “record” the user’s actions, and generate test scripts to automatically “replay” or repeat those operations.

They make it possible to edit and modify the tests by selecting objects and specifying user actions to simulate them.

The difference between simulation and validation in this method is:

  • Simulation: The capturing of the simulation of the script is easy using record/playback systems. Testers perform user actions, and the system generates a relative script using simple scripting languages like VBScript.
  • Validation: Once the simulation is done, the next step is validation, which is problematic. The explicit addition of steps to the script to identify the interface elements and compare the expected and actual values is done. These validations cannot be recorded as they are performed sequentially using the GUI of the automation system.

2. A “Real” programming language code

The advanced testers, instead of using record/playback functionality, prefer to write their code. Frameworks like Appium, Microsoft Coded UI, and Selenium allow testers to write test scripts from scratch using languages like Java, C++, PHP, or JavaScript.

These languages may or may not be similar to the language used in the application being tested.

The frameworks provide special commands such as identifying screen elements, selecting menu options, clicking, typing, and more on the application currently under test.

Most of the test automation frameworks also provide support for record/playback scripting.

The difference between simulation and validation in this method is:

  • Simulation: Selenium offers single-line commands to select objects, click, wait, or do any other UI operation. So, if the tester knows the language, it is relatively easy to automate using these built-in commands.
  • Validations: As with record/playback, in the writing code method too, this section is challenging. Although Selenium helps in locating the system’s output objects interface, the “assertions” are not supported. That means the testers will have to write the code on their own to check for expected values. Unlike simulation developed and maintained only once per user action, validation code has multiple parts for each interface element to be tested.

3. Keyword/Data-driven Scripting

In some testing tools such as Robot Framework, testers specify the “keywords” to automatically generate a script for the system under test to perform the desired actions.

A similar variant to this approach is the data-driven approach. The same test repeats several times, and each time with different data values or user operations. For example, purchasing different items every time with different options and then analyzing the results.

A table by the tester, in this case, will be provided specifying the complex set of tests with the respective operations and data.

This type of test script generation’s main advantage is that there is no need to simulate user operations repeatedly for every test script. Instead, they are defined in one place for the tester to use in multiple test scripts.

Let us consider an example of checkout using the Debit Card payment option:

The keyword “checkout” specifies that the script should navigate to the cart page and allow the user to enter payment details. A developer then writes the code to implement this functionality. The table provided by the tester will be:

 Card NumberExpiryCVVName on Card
Enter Payment details1234-1234-1234-12342/20***John

The tester can also provide lines of text like:

  • Open Cart Page and click the payment details tab.
  • Enter Card Number
  • Enter the card expiry date
  • Enter CVV
  • Enter Name on Card
  • Go to Payment Gateway

A test script that knows how to implement the above lines of text will be generated.

The difference between simulation and validation in this method is:

  • Simulation: This part of the script can be handled easily by one “keyword” defining the user action.
  • Validation: This part requires multiple keywords and expected data values for each UI part that must be validated. It is not very difficult for the tester to specify different keywords for different functionalities, but this means testers will have limited validation options and will have to rely on development to add more options.

How to Run a Test Script?

A tester cannot produce a “generic” test script to run on any automation system or port the tests from one system to another without conforming to the test framework.

Automation frameworks, sometimes called test harnesses, run test scripts.

These frameworks (Selenium, Appium, HP QTP, and Robot Framework) can take a script written as per specifications and load the user interface, simulate user actions on the interface, and report the results.

For running the tests, the following methods are used:

  • Continuous Integration Environment: If developers build the software automatically using tools such as Jenkins or Teamcity, the automatic test scripts can be run as part of the build process.

So, specific automated tests of the user interface will run and report each new build’s results. It can be used for lightweight tests like unit tests.

  • GUI-based framework: In a GUI-based framework like HP UFT the testers can select the tests from a list and click on a button to run or schedule them at various times.
  • Code-based framework: In code-based frameworks, the testers open the IDE (like Selenium), compile, and then run it. When the code executes, parts of the test framework activate and perform the interface’s required actions under test.