QTP Tutorial #3 – Adding Standard Steps From Keyword View

This is a tutorial #3 in our QTP Training series. Check out the first two QTP tutorial in this training series here: QuickTest Professional (QTP) tutorials

Adding Standard Steps From Keyword View

In last tutorial we saw how to work with keyword view.
Today’s article is going to be about adding steps to a QTP test from the keyword view. Before we go about adding the steps, let’s see what kind of steps we can add at all:

1. Standard Step: A standard step is anything that acts on an object. For example, a set operation on an edit box with a particular value or selecting a value from a list box.
2. Checkpoint Step: Checkpoint is a step in a QTP Test that compares an expected value of a specific property/state of an object with the actual value. This is a kind of validation that QTP provides to the users to make sure their AUT is working as intended. So, when this kind of a step is inserted, QTP performs a check during this step execution and if expected and actual values are same, the checkpoint passes or else it fails. An example of a checkpoint is, if in an application a checkbox is supposed to be ON after its selected or a particular name that a text on the screen should be, etc. QTP has 10 checkpoints that it provides the users with. Apart from these, the tester can verify and validate any conditions by programmatically writing them. All the check points will be dealt in detail in the coming articles.
3. Output value: As the name implies an output value is nothing but a variable that stores the outcome of a particular step in a test. This value can be used subsequently as an input for another step. This value is only available for the time period of a test run after which it gets reset. This topic also will be detailed out shortly.
4. Comments: Any step that is a non-programmatic and won’t be executed, but is put in the script to increase readability is a comment.
5. Conditional and Loop statement.
6. Other: These are the kind of statements that help in designing the programming logic. Some examples are sync statement, writing into test results etc.

Let’s start with adding a standard step. For our convenience I am going to explain the use of only item, operation, value and documentation columns in the keyword view. Though there are two more columns, they are seldom used.
Inserting a step is the first part of adding a line to a program. A step merely adds a blank line in your test. It is up to the tester to define the step and to add details to the step. The details include what item to act on, what operation to perform, what value to assign etc. If it’s a new test, any step we are trying to add becomes the first step. From the menu main, select Insert-> New Step after clicking anywhere in the keyword view.
[Note - click on any image to enlarge]

Another way is to right click on an existing step and selecting Insert new step from the menu.

Both of these option result in the addition of a new line after the selected step. If a container object was selected while adding a new line, the new step gets added as a sub-step. If a last-level object was selected, the new line gets added as a sibling.
Here is how the new line looks like. The new line added is nothing but a skeleton that can be defined as required.

So, the first thing you see in a newly inserted line is a ‘Select an item’ drop down.

Given the fact that everything operation needs an object to be performed on, this is inevitable. Now as we already discussed item can be anything, a Test object, Statement, Utility Object or comment. The Test objects that are contained under a Container Object are displayed here. Therefore, according to our example, Agent Name, OK, Password is displayed in the list when a new step is to be added while clicking on or under the sub-level steps of the Login Dialog.
Object Repository:

If anything other than the items listed are required by the user there is an option to select the same from Object Repository. Now, this is the first time in our articles that we have encountered the word Object Repository. So, what is it really? When we try to put it simply, an Object Repository is what its name suggests. It a place or more like a database where all the Objects in a test are stored. This is what happens when the user chooses ‘Object Repository’ from the list.


So either from the list displayed or from Object repository an item can be selected. The next thing is to define the operation to be performed on the selected object. Click in the Operation column and a list of operations that can be performed on the selected object are displayed. This list is dependent on the type of object selected. For instance, a dialog object will have different methods available than when an Edit box is chosen.
Choose the desired operation

The next column is the Value. As we already know that this column is the argument to the operation to be performed on the selected item. On clicking in this column, the arguments are displayed as shown below:

If more than one argument is required to carry out the said operation, all the arguments will be displayed as multiple cells in the Value column.
The type operation on the ‘FlyFrom’ item needs a keyboard input. When the icon in this column is displayed the following dialog is displayed that helps the user to configure this value.
As you can see from the window above, the value to be entered in this field can either be a ‘Constant’ in which case the constant value can simply be typed in the text box and then followed by clicking the ‘OK’ button in the window.
Or it could be parameterized, which means it would be picked up from a location in the data sheet, a random number or an Environment variable. How to parameterize a value for an argument will be discussed in length later on.

In our example, I am writing “Test” in the constant field and clicking OK and here is how the line generated looks:

It should be noted that the ‘Documentation’ field gets auto-populated with the description pertaining to the operation performed on the item selected.

Conclusion

So, that concludes the topic, ‘Adding a standard step to a test from the Keyword View’. We have discussed the various kinds of steps that can be added from the Keyword view and explored the adding of a Standard Step in detail.
We’ll have couple of more articles on QTP keyword view. In the coming articles, we will see how to add the other kinds of steps, adding conditional and loop statements and how the Keyword view can be used to modify/delete the test steps.
*****
We need your feedback to improve this QTP training article series. Let’s make it more interactive. Add your questions in below comments. Join our email newsletter as there are many more articles to come in this series.
Believe us this will be the most comprehensive QTP training article series you’ve ever seen online!