{"id":17431,"date":"2020-04-15T20:04:39","date_gmt":"2020-04-15T20:04:39","guid":{"rendered":"https:\/\/applitools.com\/?page_id=17431"},"modified":"2022-09-27T11:41:16","modified_gmt":"2022-09-27T18:41:16","slug":"test-scripts-101","status":"publish","type":"page","link":"https:\/\/applitools.com\/learn\/concepts\/test-scripts-101\/","title":{"rendered":"Learn – Concepts – Test Scripts"},"content":{"rendered":"\n
What is a test script? There are many definitions, but we’ll focus on the one that seems to be the most common in the field and the most practical for today’s QA professionals:<\/p>\n\n\n\n
A test script<\/strong> is code that can be run automatically to perform a test on a user interface. The code will typically do the following one or more times:
(1)<\/strong> Identify input elements in the UI, (2)<\/strong> Navigate to the required UI component, wait and verify that input elements show up, (3)<\/strong> Simulate user input, (4)<\/strong> Identify output elements, (5)<\/strong> Wait and verify that output elements display the result, (6)<\/strong> Read the result from the output elements, (7)<\/strong> Assert that output value is equal to expected value, and (8)<\/strong> Write the result of the test to a log.<\/p><\/blockquote>\n\n\n\n
For example<\/strong>, if you want to automatically test the login function on a website, your test script might do the following:<\/p>\n\n\n\n
- Specify how to locate the \u201cusername\u201d and \u201cpassword\u201d fields in the login screen \u2013 say, by their CSS element IDs.<\/li>
- Load the website homepage, click on the \u201clogin\u201d link, verify that the Login screen appears and the \u201cusername\u201d and \u201cpassword\u201d fields are visible.<\/li>
- Type the username \u201cdavid\u201d and password \u201c16485\u201d, identify the \u201cSubmit\u201d button and click it.<\/li>
- Specify how to locate the title of the Welcome screen that appears after login \u2013 say, by its CSS element ID.<\/li>
- Wait and verify that the title of the Welcome screen is visible.<\/li>
- Read the title of the Welcome screen.<\/li>
- Assert that the title text is \u201cWelcome David\u201d.<\/li>
- If title text is as expected, record that the test passed. Otherwise, record that the test failed.<\/li><\/ol>\n\n\n\n
You’ll notice we added a broken line after step #3, to separate between two important parts of the test script:<\/p>\n\n\n\n
- The simulation part of the script<\/strong> \u2013 steps 1\u20133 are responsible for simulating the user’s behavior.<\/li>
- The validation part of the script<\/strong> \u2013 steps 4\u20138 are responsible for checking, after we simulated some user behavior, if the system worked properly.<\/li><\/ul>\n\n\n\n
Using these basic elements of GUI automation, simulation and validation<\/strong>, you can test even very complex multi\u00adstep operations. In complex test scripts these elements will repeat themselves several times, each time for a different part of the user’s workflow.<\/p>\n\n\n\n
Now that we understand what a test script is, there are a few questions remaining:<\/p>\n\n\n\n
- How do you create the test script?<\/a><\/li>
- Do you need to write code, and what kind of code?<\/a><\/li>
- How do you run the test script?<\/a><\/li>
- How can you create enough test scripts to achieve good test coverage?<\/a><\/li><\/ul>\n\n\n\n
We’ll cover the answers to these questions in the sections below.<\/p>\n<\/div><\/div>\n\n\n\n
\nHow Do You Create a Test Script?<\/h2>\n\n\n\n
There are a few different ways to create automated testing scripts: record\/playback, keyword\/data\u00addriven scripting, and directly writing code.<\/p>\n\n\n\n
Record\/Playback<\/h3>\n\n\n\n
You are probably familiar with tools like HP Quick Test Professional<\/a> (now called UFT), which help QA professionals create automated tests. With these tools, testers can perform a set of user actions on an application or website, \u201crecord\u201d those user actions, and generate a test script that can \u201cplay back\u201d or repeat those operations automatically.<\/p>\n\n\n\n
QTP and similar systems identify objects in the user interface being tested, and enable testers to view the hierarchy of objects in the application under test. It is possible to edit and modify tests by selecting from these objects and specifying user actions that should be simulated on them.<\/p>\n\n\n
\n<\/figure><\/div>\n\n\n
It’s important to note:<\/p>\n\n\n\n
- The simulation part<\/strong> of the script is relatively easy to capture with record\/playback systems. You perform the relevant user actions and the system creates a script.<\/li>
- The validation part<\/strong> is more difficult. After simulating the user actions, for each and every element you want to check on the screen, you need to explicitly add steps to your script. These steps will identify these elements in the interface, and compare their values to expected values.
For example, if you want to test that the welcome screen says \u201cWelcome David\u201d, and also that 10 items of information are correctly displayed below, these are 11 different validations and you will need to add steps to your script to check each one of them.
You cannot record these validations<\/strong> because they are not user actions \u00ad you need to define them one by one using the automation system’s GUI.<\/li><\/ul>\n\n\n\nRecord\/playback systems do generate test scripts behind the scenes \u00ad but they are typically written in simple scripting languages like VBScript. Advanced users can (and typically will) go in and manipulate the code directly to fine\u00adtune how a test behaves.<\/p>\n\n\n\n
For a comprehensive list of guided test automation systems like QTP, see Wikipedia’s list of GUI testing tools <\/a>and list of web testing tools <\/a>.<\/p>\n\n\n\n
Keyword\/Data-Driven Scripting<\/h3>\n\n\n\n
Some testing tools make it possible to define a set of \u201ckeywords\u201d which specify user actions. Testers can specify these keywords and a script will be generated that performs the desired actions on the system under test.<\/p>\n\n\n\n
For example, the keyword \u201clogin user\u201d might designate that the script should navigate to the login screen and enter certain user credentials. A developer has to write code behind the scenes that implements this functionality, and then a tester can provide a table like this:<\/p>\n\n\n\n