July 2, 2009

Selecting from a Drop Down List

Filed under: Automation,Scripting — Marcus Tettmar @ 1:12 pm

A project I’m currently working on involves populating data into a rather poorly designed user interface.  A particular challenge were the drop down lists and list boxes due to the fact that you can’t “drill down” by sending the text of the item you want selected.

The solution we settled upon uses the text capture function GetTextAtPoint in a loop which arrows down the entire list, with GetTextAtPoint capturing the text in the selection box to see if it’s the value required.  If it is we stop, else we continue to press down and loop.  We stop if the item selected is the same as the previous item, signifying that we’ve reached the end (obviously this assumes the list doesn’t have duplicates appearing together).

Here’s the subroutine:

SRT>dropDownSelect
/*****
Usage: GoSub>dropDownSelect,X,Y,text_to_select

Where X and Y are coordinates in the edit box (where the item appears once selected)
 and text_to_select is the text you want selected  

Important: the drop down needs to have the focus
*****/
  If>dropDownSelect_Var_3<>
    GetTextReset
    Press Home
    Wait>0.1
    Let>prev_comboText=Z@$%#XXX
    Let>dropDownFound=FALSE
    Label>select_drop
    GetTextAtPoint>dropDownSelect_Var_1,dropDownSelect_Var_2,comboText,c
    Pos>dropDownSelect_Var_3,comboText,1,p
    If>p<>1
      If>prev_comboText<>comboText
        Press Down
        Wait>0.2
        Let>prev_comboText=comboText
        Goto>select_drop
      Endif
    Else
      Let>dropDownFound=TRUE
    Endif
  Endif
END>dropDownSelect

So, for example, you could call it something like:

Press Tab
GoSub>dropDownSelect,240,355,Apples

Note that the drop down needs to be focused. Usually you’d be “tabbing” through fields on the form, so once you’ve used “Press Tab” to get focus onto the control you can call dropDownSelect.

This version requires that you pass the X,Y screen position of the text box area of the drop down. In development at the moment we have a new function which returns the handle of the currently focused object, and this can then be used in GetWindowPos to get the X,Y position. So in future you will be able to determine the X,Y position dynamically.

Hopefully you won’t need this function as you can usually “drill down” on a list box or drop down list by sending the text of the item you want as mentioned here. But for those badly designed controls that won’t allow that this function can be a life saver.

June 3, 2009

Make it Easier with a Few Basic Windows Skills

Filed under: Automation,General — Marcus Tettmar @ 10:17 am

Some pre-sales questions we get seem to suggest that the user lacks basic Windows skills.  What surprises me is that these questions are often from people working in company IT departments.  Their ability to comprehend how to automate something appears to be diminished by their inability to use a PC effectively.  Perhaps I’m being unfair – I guess it’s easy to forget that there’s another way to do something.

For example.  We might get asked:

“How do I make my macro click on a desktop shortcut if I don’t know where that desktop shortcut is going to be, and I want the macro to work on any PC where the desktop shortcut could be in different places?”.  

Think about it for a second. The answer is that you do NOT click on the desktop shortcut.  Why would you?  The clue is in the name – a shortcut is .. a shortcut to something.  Why would you record or write a macro that clicks on an icon when the macro simply needs to run whatever the shortcut runs?  Right click on the shortcut to show its properties and look at what the shortcut executes.  Copy that into your script and have the Run or ExecuteFile command run it.

As I said in Top Tips for Reliable Macros: Don’t automate mouse clicks or keystrokes just to start an application!

Now, even if you did want to select a desktop shortcut, there’s still another way to do it without needing to know or care where it is.  Just type it.  If you focus the desktop and type the name of a desktop shortcut on the keyboard it will get selected.  This is what I call “drill down” and it works on most lists.  So your macro could just send the text of the item.

When we get asked questions like this I’m always a little surprised.  I would have expected someone in an IT department to know what a desktop shortcut is and also to know that you can control Windows via the keyboard.

Of course, if you really, really want to create a macro that double clicks on a shortcut using the mouse and want it to find its position you can do that with image recognition.  In some applications, like the one I wrote about yesterday, that is the only way to go.  But it’s overkill if you just want to start an application, or run a file.

See also: Keyboard Shortcuts; Top Tips for Reliable Macros

June 1, 2009

Easy to Use is Easy to Automate

Filed under: Automation — Marcus Tettmar @ 2:54 pm

I’ve just finished writing a routine for a customer that automates what I can only describe as a truly horrendous user interface.  I’m not sure who designed it or why they designed it the way they did but I feel sorry for people who have to use this software.  And apparently it is the industry leading software in its niche.

The software is devoid of keyboard shortcuts and there are no menu items. The only way around the software is by clicking the mouse on icons which have no way at all of gaining keyboard focus – no keyboard short cuts and you cannot even Tab to them.

The main data entry screen has a few accelerator keys (shown by an underlined character) dotted around but they are duplicated and don’t seem to work anyway!  So on one screen ALT-S would appear to focus three different fields, but in fact focuses none.

Once logged into the system it would seem the only way back to the main menu is to exit the app and restart it.

The only way to add a customer record is first to search for one.

And this is just the start of it.  

Luckily Macro Scheduler gives us image recognition and screen scraping abilities so even this dreadful user interface can be automated.  We did it.  But I had to spare a thought for the people who use this software every day.  Everything takes twice as long to do as it needs to.  It can’t be fun. It also suggests that the UI wasn’t tested and no consideration was made to its accessibility.

As I said in Why it’s Good to Automate:

Build an application with good keyboard support and your application can be automated more easily. If it can be automated easily it will be easy to use!

Sure there are some types of software where only an image based approach makes sense. But this particular app is just a way to view and manage customer information.

Sorry for the rant. But it just helps to demonstrate how a decent UI can be more easily automated. While we have tools such as image recognition and screen text capture that will help us automate cumbersome interfaces, a well designed UI can be automated more quickly and more efficiently. It also shows how automation can help test an application and ensure it is accessible. If a UI is well designed the UI can be tested, and looking at it the other way around, if the app can’t be automated easily then perhaps the UI is hard to use, especially for people who cannot use a mouse, or rely on screen readers.

May 19, 2009

Multiple Monitors aid Productivity and Debugging

Filed under: Automation,General,Scripting — Marcus Tettmar @ 3:20 pm

If you’re not using more than one monitor, you are missing out big time.  For one thing, some research by the University of Utah found that using two monitors increases productivity 44%.  There’s a good summary and more comment on this on the coding horror blog.

A huge benefit of multiple monitors for Macro Scheduler developers is that it makes developing and debugging automation macros a lot easier.  When I’m building a script that controls another application I will often put the Macro Scheduler editor on one monitor and the application I’m automating on another.  I can then see both side by side, so I don’t need to switch focus back and forth.  I can run my macro as I’m developing it and see the script at the same time as the results.  If I need to debug I can step through the script and see the progress of the script at the same time as the outcome without the changing of focus effecting it.

Debugging a script that simulates a user and needs to change focus can be a bit of a conundrum, since the act of debugging introduces delays, allowing more time for events to complete, and causes loss of focus.  In Macro Scheduler there’s a “Refocus Windows” setting in the Debugger, but even that isn’t enough in some cases.  Being able to work on the macro and see the target application at the same time without either interfering with each other is therefore the best solution.  

If you don’t have a PC or video adaptor that can support more than one monitor you could use ZoneScreen along with a laptop or second PC to act as your second screen.  A single monitor big enough to let you put the editor and target apps side by side without them overlapping would work too.

If you’re stuck with a small monitor and simply can’t have both editor and target application visible at the same time – you may be at a client’s site or working on a notebook – and need to debug code that needs to see the screen, don’t forget you can also set and run to breakpoints.  With a breakpoint you can step through the code and at any time run to the next breakpoint, allowing the macro to whizz through the code to that point without switching focus back to the editor between each step.  So for crucial sections of code which need to, say, capture a screen or scrape some text, it can be very useful.  Once the script reaches the breakpoint you will be returned to the editor where you can continue stepping line by line, or run to the next breakpoint or end.

In my opinion multiple monitors are an absolute must.  But there are limits!

May 14, 2009

Multiple Desktops for Load Testing or Increased Throughput

Filed under: Automation — Marcus Tettmar @ 10:40 am

A question arose in the forums the other day from someone looking at running some scripts for load testing and wanting advice on how best to run multiple instances of the same script.  See the thread here for some useful ideas and links. I thought I’d summarise them here.  

An article on using Macro Scheduler for load testing can be found here.

If you are new to load testing you might not be aware of the options available to you for multiplexing desktops. Obviously you can’t run a script that interacts with the desktop – focuses windows, sends keystrokes and mouse clicks etc – more than once at the same time on the same desktop. Chaos would ensue. If you want to simulate a bunch of users interracting with an interface you’re going to want lots of desktops running at the same time. You could, of course, use lots of real PCs. But that’s a rather expensive approach, especially if you want to run 100 or 200 users at the same time.

Here are some commonly used options:

Windows Terminal Server – Remote Desktop

Windows Server 2003/2008 allows multiple desktops to be active at a time. The standard version comes with a license for up to 5 simultaneous client connections (CAL – Client Access License) and you can buy further CAL packs to increase the number of simultaneous desktops you can have at any one time.  

You can then run multiple desktops – either for the same login, or different users, and have scripts running in each one.  So with one physical machine you can run multiple desktops to simulate multiple users. Clearly the more desktops you run the more the effect on performance, and since you may be trying to test the effect on performance there’s a balance. Many companies will run, say 10 physical machines, running, say 20 desktops each, to give you 200 virtual users.

One thing to consider with this approach is that since each desktop is running on the same machine you should be careful that your scripts don’t try to write to the same resources and cause conflicts – e.g. if they all try to write to the same file at the same time.

Virtualization

Virtual PC is a free product from Microsoft that lets you create virtual machines. You can create a machine, install, say, Windows XP, into it and run that machine in it’s own window on your desktop. You could therefore create multiple virtual machines and run them simultaneously. Each have their own desktop and therefore UI automation routines can run in all of them simultaneously. Unlike with Remote Desktop each desktop is completely separate from the other so you would have no issues with accessing local resources. You would have to consider the Windows licensing implications and how the cost compares to Windows Server client access licenses.  

Creating multiple virtual machines can also take some time, whereas with the remote desktop approach the operating system only needs to be installed once. There is a way to clone virtual machines by copying the VHD files and then running NewSID in the machine to give the OS a new security ID.

VMWare Server is another virtualization platform. There’s also Parallels. Again, when cloning virtual machines you’d have to make sure they have different SIDs. VMWare offers a solution called Lab Manager which I believe is intended to make the process of provisioning multiple machines easier, though I’m not experienced with VMWare.

In each case you would want to ensure that the approach you use isn’t adding to the performance bottleneck or it might make the tests pointless. Verify how many virtual machines or desktops your server can cope with and find the right balance.

You may need to run multiple copies of the same (or different) scripts at the same time for other reasons and these tips will be valid in this case too. For example we’ve worked on automation scenarios where lots of data needs to be entered into a legacy user interface. The data may arrive at different times.  Rather than work through the queue one at a time, multiple desktops are fired up for each item so that there are lots of tasks taking place at the same time, therefore speeding up the entire process.

See also:
Running UI Automation Routines Concurrently

May 12, 2009

The Variable Explorer

Filed under: Automation,General,Scripting — Marcus Tettmar @ 2:15 pm

An experienced Macro Scheduler scripter was recently trying to figure out why the following code wasn’t doing what he expected:

If>seg_1=05
  Let>monLtr=mm
Endif

Apparantly monLtr was always being set to 05.  This told me that “mm” must have been a variable which had earlier been set to 05.   But my friend said “I’ve looked all through the code I can’t see where “mm” is set anywhere”.  

Then I reminded him of the Variable Explorer.  “The what?” he asked.

varexplorerUnder the editor select Tools/Variable Explorer or hit Ctrl-Alt-V and you’ll get a box like this one.  It shows a list of all the variables created by your script.  

Bingo!  There’s mm.  Expand it and you’ll see all the lines where it is set/created.   In this case it’s created on line 40 by the Min command.  

In a long script it’s easy not to see the obvious.  The Variable Explorer makes it easier.

Of course, it would also be sensible to use a better naming convention for the variable to avoid such confusion.  Or use VAREXPLICIT or he could have used {“mm”} to specify the literal string value.   But don’t forget the Variable Explorer as it can save a lot of hunting around.

May 11, 2009

Test Validation Techniques

Filed under: Automation,Testing — Marcus Tettmar @ 1:42 pm

We recently received the following query to support:

I’m interested in Macro Schedular for GUI testing. How do I verify that the test has succeeded or not? 

I thought it would be useful to post my response here:

There are a number of ways you could do this. Which one you use might depend on the type of application you are automating, or your specific requirements. You could:

  • Capture object text to see if it contains the data you would expect using such functions as: GetControlText, GetWindowText or Windows API functions. See: http://www.mjtnet.com/AutomatedTesting.pdf
  • Capture object and other screen text using the Screen Scraping functions: GetWindowTextEx, GetTextAtPoint, GetTextInRect. Compare captured text to expected data. There’s a sample script called Text Capture which you can use to test what text you can capture. Run it, and point the mouse cursor at the text you want to capture and confirm you can see it on the dialog. See Screen Scrape Text Capture Example and Screen Scraping with Macro Scheduler
  • Compare visually: Capture screen shots (or just windows) and compare the captured bitmaps with bitmaps captured at design time. Use the ScreenCapture and CompareBitmaps functions. This solution has the benefit of working with ANY technology on ANY platform. When you create the routine you capture the screens as they should appear when valid. So at runtime after entering data and controlling the app the macro would capture the screen/window and then compare to the valid images thus determining success or failure. See: How to use Image Recognition
  • There may be other options, especially for non-UI processes, such as reading data from the apps database (using DBQuery) or reading from a text file (ReadLn, ReadFile) or CSV file, checking the existence of files etc – depending on what the application you are testing does and what signifies a valid outcome.

Are you using Macro Scheduler for automated testing?  What types of app are you testing and what methods are you using?  Please comment below.

April 23, 2009

Macro Microdecisions for Macro Economic Impact

Filed under: Automation,General — Marcus Tettmar @ 8:09 am

While many of our customers use Macro Scheduler for automating key business processes I would hazard a guess that a large number of people are using the tool to automate smaller tasks related to their own individual work. In themselves these tasks may not appear too important, and may not even be visible to the upper echelons of management concerned with improving efficiencies of larger systems. But, improving the efficiency of many small tasks can have a big impact on the overall profit and loss of a business.

In “Microdecisions for Macro Impact” on the Harvard Business Review blog, Tom Davenport talks about how small decisions made lots of times by many employees can have a major impact on the business. How these small “microdecisions” are addressed and improved can impact overall performance.

Tom suggests that one approach to improving a micro-decision is to automate it. Automation of a repetitive task not only speeds it up but removes the chance for error. It also frees up the employees’ time to work on other matters. This will come of no surprise to my regular readers and Macro Scheduler users.

As the article mentions, one simple way to improve micro-decisions is to create a checklist to ensure the worker does not miss any key steps. Another common approach is to draw up a flowchart. With Macro Scheduler Pro Enterprise we can combine flowcharts with automation. Macro Scheduler Pro Enterprise includes Workflow Designer which allows you to flowchart a process graphically. This is a great way to analyse and document a business process. Unlike regular flowcharting tools however, once the flowchart has been created and refined you can then start adding real code to it. You then have a documented process which can actually carry out the task for you. The documentation evolves into the solution. If you’ve timed the manual process you can then find out what kind of efficiency savings you are making by analysing the log files (or building in timers in your code) and comparing.

A little goes a long way – automate lots of small procedures like this and you could boost your organisation’s overall performance.

April 13, 2009

We can Automate Your Task

Filed under: Announcements,Automation,Scripting — Marcus Tettmar @ 8:01 pm

We don’t just sell great automation software.  We can also build your task for you.

If you don’t have the time, know-how or technical resource to automate your task yourself you might want to check out our new We Can Build It service.

We’ve been doing custom script development for years but have never actively promoted it as a separate service.  Now, with our We Can Build It service we can take a look at your process and automate it for you.

Many people reading this blog are already using and benefiting from Macro Scheduler and happily automating their tasks themselves.  If you’re one of those people you probably don’t need this service, but you may know someone else who does.  If so please pass this post on to them.  

For more information or to find out if your task is a candidate for automation click here.

March 11, 2009

Workflow Designer 2.1 Released: Export to SCP Files

Filed under: Announcements,Automation — Marcus Tettmar @ 10:10 am

Workflow Designer 2.1 is now available with the following changes:

  • Added: Ability to export workflow diagrams to Macro Scheduler script files
  • Added: Ability to add top/Left Rulers
  • Updated MacroScript engine to 11.1.05
  • Change: Visio style grab handles
  • Fixed: Opening Editor under Vista with UAC enabled would sometimes not work
  • Fixed: Some unicode encoding issues

MacroScript Workflow Designer 2.1

Workflow Designer allows you to create automation routines in flow chart form. With Workflow Designer you can create a flow chart of your process and then add the code to make it run. Logic is easily defined using decision boxes, and branching is as easy as joining boxes up. If code needs to be moved simply drag code blocks to where you want them to be and reconnect them to change the flow.

With Workflow Designer 2.1 we’ve added the ability to export a Workflow to a regular Macro Scheduer script file. This means Workflows can now be compiled to .EXE files using Macro Scheduler Pro, used in other Macro Scheduler installations, or easily integrated into existing scripts.

Workflow Designer is shipped with Macro Scheduler Pro Enterprise.

Registered Downloads/Upgrades | Evaluation Downloads | New License Sales

« Newer PostsOlder Posts »