Test Script Page
Last updated
Last updated
The test script page is designed for either creating automation scripts or converting manual test steps into automated test steps with just one click.
We can access the test script page through the navigation path: Automation > UI Testing > Test Script
"The test script page contains the following sections:
Choose Manual Test Case
Basic Details
Debug Test Script
Automate Manual Test Step
Add or Select Test Data
The 'Choose Manual Test Case' section is used for retrieving manual test case details from the QAbunch manual test case section
By default, the section is in collapsed mode. Once you expand the section, you can see the Test Case Management Tool and Manual Test Step sections.
Once you provide the Test ID, the manual test case details are fetched from QAbunch. The information can then be viewed in the Basic Detail section and the Manual Test Step section
QAautoMATER generates automated steps based on Manual Test Steps. Manual Test Steps can also be in BDD format. Additionally, you can paste the test steps directly into the Manual Test Steps section. Whatever values are present in the Manual Test Steps section will be used to generate automation step
All the steps in the Manual Test Step section will be converted into automated steps after clicking the 'Generate Automated Step' button. In the Manual Test Step section, test steps can be fetched from the test ID, or you can also manually paste the test steps.
Video file for Choose Manual Test Case section
Basic details have three sections:
1. Component : Provide the new test script component name.
2. Test ID : Provide the new test script id.
3. Test Name: Provide the new test script name.
Please note : when Test IDs are fetched from the 'Choose Manual Test Case' section, all three values will be auto-populated based on the test details.
Users can also manually add or select a component or test ID. Both the component and test ID are represented as combo boxes. In the case of a new component, type the component name; for an existing component, select the component from the listbox. Similarly, for the Test ID.
The Test Script page is also designed for updating existing automation scripts. To update the test script, select the existing component and test ID. After selecting the test ID, the test steps table will auto-populate.
The Debug Test Script section is used for debugging specific test steps in test scripts
The Debug Test Script section has four keys: environment, application URL, screen, and device. These values are derived from the configuration page, and based on the default environment selection, the environment and application URL are generated. If you update the environment, the application URL will be changed accordingly. Additionally, the default screen configuration from the configuration page is displayed on the test script page
After clicking the Debugger window, the selected application URL will be launched on the chosen device and browser. However, you can also update the application URL manually.
For debugging the test script, select the radio button from the 'Automate Manual Test Step' table and click on 'Debug Step.' After clicking the 'Debug Step' button on the debugger window, you can view the results. In case of failure, you can identify the root cause of the failure.
The 'Debug Page Function' button is used for debugging page functions, which can be viewed under the 'Select Pre-dependent Page' section.
Please note: When debugging all the steps, always close the debugger window using the cross icon. It is a mandatory step
The 'Automate Manual Test Step' section contains two subsections: 'Predependent Page Function' and 'Test Step.
By default, the 'Select Predependent Page' section is in a collapsed view. After expanding, you can select the predependent page section. For example, in a Real application, if your test case is designed for the shopping cart page, then from the custom page function, create'User is on cart page' so that you can reach the shopping cart page. Generally, page functions are used for navigating to the respective pages.
For adding a new step, click on the 'Add Step' button. The new step will be displayed as the last step. If you want to add a step between two existing steps, select the radio button for the test step after which you want to create a new step. The new step will then be created between the two selected steps
A test step has the following fields:
a. Step definition
b. Action
c. Web element
d. Value
e. IsReportingRequired
typically refers to a statement or description that defines a specific action or behavior to be performed during the execution of a test case
Step definition is a key factor in QAautoMATER. Based on the step definition, it generates the action and web element
Recommendation:
Please write step definitions accurately with significant meaning. Write shorter step definitions, for example, 'Click on the Login button' or 'Select Country from the listbox.'
If an object has more than one word, then put it into single quotes. For instance, 'Enter 'Routing Name'.
"action" refers to a specific operation or behavior that is performed during the execution of a test step
After clicking the Action cell for a test step, you will get the 'Choose Web Action' dialog
All actions are categorized into different categories, such as UI action, Browser action, etc. Depending on the test step selection, expand the relevant category.
After expanding the (+) icon for an action, you can see the objective of the action along with examples.
Once you select the radio button for the action, it will be automatically updated in the Action column for the test step section, and the dialog will be closed.
The Web Element cell for the test step refreshes the web element logical name. After step definition, the web element will be automatically created. In case the web element is not generated automatically or after debugging the test step, and the step is failing, you can add or update the web element
Once you click the cell of the Web Element column after providing the step definition and action, the web element dialog will be displayed.
The web element name is the logical identifier for the web element. For example, for a login button, the logical name could be 'ButtonLogin.' We recommend always using a prefix to assist other team members in searching for the object. It is a combobox where we can select an existing web element. To add a new web element, provide a logical name
Locator is the type of property used to identify the element. The locator values are populated from the configuration page.
Locator property is the value of the locator.
After providing all the details, the web element logical name will be linked to the test step. In case of removal, you can click the 'Remove' button from the web element dialog, and the web element will be removed from the test step."
IsReportingRequired has two values: Yes or No. If you select Yes, and during the execution of the test step, it fails, the entire test execution will be aborted, and the next step will not be executed. If you provide No, the next step will be executed even in the case of failure, and it will not be added to the reporting.
If you do not provide a value, after saving, it will automatically be set to Yes."
The "Add or select test data" section is utilized for mapping test data into test steps. By default, it is in the collapsed mode. Upon expanding the section, you can observe the presence of the "Common Test Data" section, "Test-Related Data" section, and the "Utility Data" button.
Test data that can be utilized in multiple test cases can be added to the Common Test Data section. For example, if there are five test scripts for the search result page, all using the same search key, in such cases, it is advisable to include the data in the Common Test Data section.
To add new test data, click on the "Add" button in the Common Data section. A new row will be appended. Enter the data key name in uppercase and provide the corresponding value.
Common test data can be utilized in test steps by calling c.DataKeyName. For instance, to use the search key, you would write c.SEARCHKEY in the test step.
Test data that is only used in a single test script can be added and saved in the test-specific section.
Suppose you need to verify the city based on the selection of multiple countries. In this scenario, where there is only one test script for verifying the city, the test data can be maintained in the test-specific section. To add the necessary test data, first, add a column by entering the column name such as COUNTRY in uppercase and click the "Add Column" button. Afterward, enter CITY and click the "Add Column" button.
To add data, click on the "Add Row" button. In the new row, enter the country name and city. You can add multiple countries and cities by repeating the process of adding new rows.
To consume the test data in a test step, you need to call the data key with the prefix "t.". For example, to use the country data, you should call it as t.COUNTRY, and for the city, you should call it as t.CITY.
Please note: If a row (Xrow) is added in test-specific data, it means the test script will be executed X times with the provided dataset.here test script executed twice for first iteration it pick country India and second iteration it takes country as USA
Test steps that require dynamic data every time, such as needing a unique email for creating a user, can be provided from the Utility Data section. similar for other test data like phone number, ip, url, flightnumber , ip, etc.
To consume the test data, the first step is to select the radio button in the test step.
After clicking on the Utility Data button, the utility dialog will be displayed. Select the appropriate data key and click the Update button.
Please note that you can use prefixes, suffixes, or multiple dynamic data at the same time.
Example (QAautoMATER words is used as prefix)
Example (QAautoMATER words is used as suffix)
Example (Muttiple datakey are used in same step)
How to store value into variable (SaveSessionVariable)
Our SaveSessionVariable method allows you to save a value into a variable, which can be consumed in later steps. Whatever the output of the step just above it will be saved.
For example, suppose we want to retrieve the browser title, and this title will be used in a later step. First, we call the GetTitle method. Whatever output this method returns can be saved in the next step using SaveSessionVariable
Now, this variable can be accessed anywhere in the test script using Session.mybwTitle.
Please note
1 . Session variables will work during execution but not during debugging.
Session variables can be used for storing both single and multiple variables at a time.
example 1 (Single Variable)
example 2 (Multiple variable at a time)
