EverythingSoftware Testing

Adventures in GUI Automation – getting my bearings

So I mentioned some of the inherent issues that I dislike about QTP 10. One of those appears to be that reusable actions intermittently fail. An action in QTP is a tool-defined item that collects a number of GUI manipulations (or function calls) into a named action. It sounds handy. It probably would be if it worked reliably, but it doesn’t – at least not for me. The other thing is that if you have reusable actions (let’s say for instance that you keep your common ones in a single file and call them from other files), you cannot modify those actions without first closing your current test file and opening the one where the action is defined.

Instead, I have organised my scripts into a series of user-centric actions, which I have defined as functions in function libraries. To be clearer, each function executes a series of steps in the gui that an end-user would recognise as an action. e.g. log in, navigateToQuotationScreen and so on. This seems to work pretty well. I end up with a QTP screen that looks like a high-level checklist of how to execute a particular workflow. You do not have the editing restrictions that you do with reusable actions, as you can have as many function libs open as you like.

Neato. So I’ve been using the record tool to get something that works. Mostly because I dislike VBScript. I think it’s the Orcish of programming languages (Maybe not even that. Maybe it’s Kobold </nerd>). The recording tool creates a bunch of objects and sticks them in the object repository. That’s fine, saves me having to do it myself. Drawbacks to this are that for dynamically created objects, you may end up with a bunch of identical objects with different names. Not too hard to figure out, given that you should be naming your objects something sensible anyway. You can weed out the dupes when you do this and update your script accordingly. I’m definately going to check out Albert Gareev‘s suggestion of dynamically loaded object repositories. That sounds quite handy. I will say though that at the moment I’m being assisted by some not-so-technical testers who I am weaning away from the keyword view and the active screen.

The recording tool doesn’t always use the best code for the job. It’s the same old story – want the job done right? Gotta do it yourself. After the initial script is in place, I’ve been reading through the code and separating it into user-centric actions. At the same time, I look for:

  • places where the code can be optimised
  • places where data should be dynamic
  • any fluff commands that QTP put in
  • potential duplicates in the OR

At this point, what I’ve ended up with is having a series of user-centric ‘tests’ – I’ll call them transactions. Each one is an action (as every QTP test has 1 action by default), but consists of a series of calls to function libraries.  Each function is named for a step that a user might consider part of the transaction. For example, if we were talking about a program that provides a quote for car maintenance, the list of function calls might look like this:

  • enterVehicleDetails
  • selectServiceTypeAndLocation
  • selectPreferredDates
  • completeQuotation

Each of these functions lives in an associated function library. These functions may in turn call helper functions (such as date/time functions to enter date ranges in the future). Each transaction hides the ugly details of what is going on under the hood and while you don’t get to use the ‘keyword view’ anymore, you do have a clearly labeled set of steps.

So at this point, I have some scripts. They work. They’re not robust and they don’t do any data verification to speak of, but it is a beginning. Next up – parameterization and making use of the data table.

6 thoughts on “Adventures in GUI Automation – getting my bearings

  1. Congratulations, Ben!

    Your approach is aligned well with time-proven modular/data-driven framework concept.
    In that path, you might be interested in exploring the following resources.

    “Layered Architecture for Test Automation” article

    “Relevant Codes” blog by Anshoo Arora

    Generally, all the frameworks that incorporate business/test logic in code modules eventually end up having amount of test code larger than amount of application code itself (huge maintenance issue in the long run), therefore applicability is small/mid size test suites, for Smoke/Sanity tests.

    Thank you,
    Albert Gareev

  2. I like your practical approach. I’m always trying to come up with good examples to teach testers good test automation design techniques/practices. It looks like you’re striking a nice balance here between “perfection” and something that works and is maintainable, even if not ideal. Cool!

  3. Thanks for the comments, all.
    I’ve just finished writing the verification layer which I will post about as soon as work tells me whether or not I have permission to post the actual source.

  4. Are there still issues with debugging if you have functions in external files? I ran into this previously, but then slowly found it less of an issue as I built more of my own objects and wrapper functions/classes.

  5. Depends on what you mean by issues 🙂
    You can’t use the keyword view to do any code manipulation, but to me this is more of a plus than a minus. It stops people thinking that familiarity with a tool equals effective test automation.
    As far as using the in-built debugger goes, no problem that I’ve noticed.
    About the only thing I’ve found is that if you call a function from another function, you can’t use the ‘right-click->go to function definition’ option that you have available from the main script, but I don’t find this a huge drawback.

    Were there other issues you were having?

Leave a Reply

Your email address will not be published. Required fields are marked *