Test automation for terminal emulators

This is an article for beginning Quick Test Pro users. Quick Test Pro is a test automation tool from HP (former mercury). It is sold as a record/playback tool for making test cases. I’ll describe how to automate terminal based applications. Why? Because there’s a good way and a bad way. The problem is you’ll only discover exactly how bad the bad way is after you see the good way. So if no senior automation engineers are present there’s a very good change you’ll be going the bad direction.

Forget record and playback. I’ll repeat: FORGET RECORD AND PLAYBACK. But you’ll say: “but it is working for me!”. Well yes, it is, in the beginning. Standard use of QTP works by using a repository in which a objects in your AUT (application under test) are stored, so that when replaying QTP can access them. The problem is not making the tests. It will work perfectly, but the problem lies in maintaining the tests. Most beginning engineers will have a script for each terminal emulator screen and a central repository (I do hope you’re using a central repository, otherwise you can look forward to a full-time job in test maintenance.) and a datasheet (excel).
Now here’s the problem: when a field is added to a screen, you’ll have to update the repository, the script for this particular screen and the datasheet. So you’ll need to uses the application, QTP and excel. Sounds like a lot of work? Well it is!

So what can we do? The good thing about terminal emulators is the fact that objects are very clearly and easily defined. So would it be nice if we could skip the whole repository, skip the ‘one script per screen’ and be able to customize our complete flow and screen setup from within excel. Wouldn’t that mean we could have business users write the tests? Yes it would! J

How? Make a terminal emulator framework in QTP! The explanation below is a very very very basic flow of how we could do this, but it will give you an idea:

** Make an excel sheet. Make 1 tab that will contain the flow, make one more for each screen in your application. In the first tab, have a test case on each row, so make each row a series of screens (each column is a screen). On the other tabs (screens) each row contains the data for the fields on that screen related the the row of your flow, the names of the columns are the field names of the screen in your UAT.

Tab 1 – row 1: screen1 screen2 screen3
Tab 2 (name=screen1) – row1: dataforfield1 dataforfield2 dataforfield3

** Now where going to make a driver script in QTP. In it’s most basic form it’ll do this:

Loop1 – loop every row on tab 1 (every test case)
Loop2 – loop every column on tab 1 (every screen)
Goto the right tab
Loop3 – loop every column on the screen tab (field in AUT)
Find the field in the application
Fill in the field
Submit
(check reply)
End loop3
End loop2
End loop1

** How are we going to make the driver script in QTP? Descriptive programming!! Descriptive programming is not nearly used enough in QTP. For Terminal emulators it’s perfect. With descriptive programming there’s no need for a repository anymore, you can access any object from within the script. A little example syntax:

TestObject("PropertyName1:=PropertyValue1", "..." , "PropertyNameX:=PropertyValueX")

Look it up in the help file if you’ve never heard of it. It’ll change your life. The important thing is to keep your PropertyValues out of your script and into your datasheet (for example as the names of the columns on your screen tabs).

So that’s about it. Implement the loops, add some checking code and error handling and there you have it: your automated solution in 500 lines of code or less for terminal emulators that’s practically maintenance free and can be updated by adding data,tabs and columns in an excel sheet.
I’d say have a go at it, a very basic test could be easily implemented in a day, a full blow 1000 testcase suite in a week.