June 3, 2009

T-Shirt Winner for May

Filed under: General — Marcus Tettmar @ 11:21 am

This month a fancy MJT Net logo T-Shirt goes to Rain for receiving 10 forum reputation points in May.  Thanks, Rain, for your valuable contributions on the forums and for continuing to help others out.  

Don’t forget that each month I send T-Shirts to the people receiving the most reputation points in the previous month.  So if you’re not already active in the forums, get stuck in – you could win a T-Shirt.

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 30, 2009

Regular Expressions for Dummies

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

I recently stumbled upon this series of video tutorials on Regular Expressions:

Regular Expressions for Dummies

If you want to know how to get some power of out of Macro Scheduler‘s new RegEx function you might find the above free video tutorial useful.

One resource seen in the video that I didn’t know about is RegExr – an Online Regular Expression Testing Tool.  It’s free to use and there’s a desktop version you can download too.

But my favourite RegEx tool is RegExBuddy from JG Soft.  An invaluable tool for anyone working with Regular Expressions.  The author also maintains this excellent Regular Expression resource which includes a tutorial, examples and references.

April 27, 2009

Macro Scheduler 11.1.09 Update

Filed under: Announcements — Marcus Tettmar @ 9:53 am

Macro Scheduler 11.1.09 is now available with the following changes:

  • Fixed: ExportData failing to write correct data for subsequent exports of other data labels
  • Fixed: insertion of SRT not completing autoinserted END with subroutine name
  • Fixed: minor syntax highlighting anomolies
  • Fixed: SetDialogObjectFocus caused error if object not visible
  • Fixed: ShowAllChars menu option not being remembered correctly
  • Fixed: Code Folding menu option not being remembered correctly

Registered Downloads/Upgrades | Evaluation Downloads | New License Sales

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.