July 12, 2016

Why it’s Good to Automate [Repost]

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

This is a repost from 2006.

One of the best ways to learn to use a software product fully is to try to automate it. Testers and automators have to learn the software’s interface really well, possibly better than the people who wrote it. Ok, the developers know the algorithms better than anyone else, but it is the person automating it who knows the ins and outs, pitfalls and quirks of the interface.

We all know how badly designed some Windows programs are. And in these days of fancy hi-res graphics and snazzy toolbar buttons it’s easy for the designers to forget about shortcut keys and keyboard navigation. The most productive way to use a PC is to forget the mouse and learn the keyboard shortcuts. You can get things done much more quickly. Yet even the most experienced Windows users don’t know half the keyboard shortcuts that exist in Windows (tips for keyboard navigation in Windows could be a post for another day).

Knowing these shortcuts makes automation so much easier and more reliable. Automating an application by sending mouse events and mouse clicks is unreliable and depends on the screen resolution never changing. Although you can use relative mouse coordinates, sooner or later something is going to change and the button you want to click is not in the place it was when the script was created.

The automation/test engineer is the one who figures out the keyboard shortcuts and finds the simplest, most reliable way of navigating an application. People who automate applications regularly have a good understanding of the different ways to move around Windows and Windows applications. Automated Software Testing can help find issues in the interface just from the process of building the automated test, even before the test script has been run. Building an automation routine for an application will help you find those missing or duplicated shortcut keys and other objects that can’t be driven by the keyboard.
Automators spend so much time fiddling with the software’s interface that they will often become more knowledgeable than the “power-users”. Testers also have the great advantage of being allowed to try unusual scenarios that developers never think about or are too busy to try. They are allowed to break things!

So it goes both ways. Find out the windows keyboard shortcuts and the hot-keys for the application you’re scripting and you can create a better script. 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!

November 24, 2015

Finding HTML Attributes For Automating Web Sites

Filed under: Automation,Scripting,Web/Tech — Marcus Tettmar @ 1:00 pm

If you’re new to automating IE/websites with WebRecorder or the native Macro Scheduler IE functions you may be wondering how to determine which elements and attributes to use.

In this video I demonstrate how to use IE’s F12 key to invoke Developer Tools and use that to quickly find the elements we’re interested in and the attributes we need to use:

(You might want to click on the video toolbar to select a larger resolution size, view full screen or view on YouTube so that you can see the code).

February 6, 2015

Awesome Image Recognition

Filed under: Announcements,Automation — Marcus Tettmar @ 4:36 pm

We received this email today and I just had to share it …

Macro Scheduler image recognition just saved me 6 hours of mind numbing work and my program took me about 15 minutes to write, test, and start using. Such an AWESOME solution you provide.

Richard A. San Jose, CA USA

For more info on how to use Image Recognition see:

November 25, 2014

How to Trigger an Action if the Number of Connected Monitors Changes

Filed under: Automation,Scripting — Marcus Tettmar @ 9:57 am

Today I was asked if Macro Scheduler can trigger an action if the number of connected monitors changes. Yes, all we need is a way to determine how many monitors are connected to the system. VBScript is one way to do that. So then all we need is a loop that constantly checks this value. So we end up with something like this:

October 14, 2014

The Macro Scheduler MacroScript SDK in Python

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

Did you know there was a Macro Scheduler SDK? It allows you to run Macro Scheduler code from right within your own apps. You can run and interact with MacroScript code within VB, C++, C#, Delphi, VBScript … or any other programming language which lets you use a COM object or Win native DLL.

It even works in Python. Here’s a small example which uses the screen image recognition functionality to find and click on the Windows Start button:

Another slightly more complex example which opens Notepad and types into it. It also demonstrates how you can call chunks of code at a time instead of all at once and set and get the value of script variables during execution. It also gets the result of the script set via MACRO_RESULT:

More information about the MacroScript SDK can be found here.

A number of customers have used the SDK to build macro-ing capabilities into their own products and/or create tighter integrations between their own software and automation routines using MacroScript.

If you’re interested in trialling a copy or getting pricing info drop us a line.

August 8, 2014

Detect Which Web Page IE Is On – Keep It Simple

Filed under: Automation,Scripting — Marcus Tettmar @ 9:43 am

Today we had two different support requests asking how to have a Macro Scheduler macro determine which page IE is on.

One person was asking about using Image Recognition for that. You could also use the IE functions to examine the HTML or look for the existence of a specific HTML element.

You could do one of those, sure, but I think that’s over complicating things.

My motto is “keep things simple”.

IE’s Window Title adopts the page title of the web page it is displaying. IE also shows the URL in the address bar. So why not just look at one of those. Like this:

//Two simple methods to see which page IE is at.

//Method One - Just look at the window title
IfWindowOpen>Bing - Internet Explorer
  //Bing is open - do this
  IfWindowOpen>Google - Internet Explorer
     //Google is open - do that 

//Method Two - Look at the Actual URL in the URL bar - I used the Wizard to get this code and then altered the window title to make it a substring match
UIGetValue>- Internet Explorer*,{"Address"},curVals,Positions,nHeight
  //must be at google
  //must be somewhere else
    //must be at bing

June 19, 2014

Automating Facebook and other Web Apps via Zapier

Filed under: Automation — Marcus Tettmar @ 12:09 pm

A while back someone was looking for a way to post from a macro to a facebook page. A few methods were mentioned. There’s another one which is easy and reliable and that is to use Zapier.com. I’ve made a video here to demonstrate how to set it up:

But this demonstrates a lot more potential than just posting stuff to Facebook. Facebook is really just an example. Zapier supports a huge array of other web apps, including help desk systems, CRM systems, email, google docs, popular accounting platforms and a lot more besides. The same principle as used in my video above can be used for those too. So if for example you wanted a macro to create an Invoice in Freshbooks. No problem.

So instead of having to automate the front end of these web apps or spend the time or pay a programmer to work with their API directly, Zapier is a simple solution which sits in the middle. They have a free plan too.

It would also be possible to work the other way and get data OUT of web apps. There are a number of ways to do that including writing to a MySQL database (which Macro Scheduler could read) and saving text/CSV files to a dropbox folder (which Macro Scheduler could read), sending emails (which Macro Scheduler could retrieve) and so forth. Maybe that’s another video.

I’m sure you can come up with some other cool ideas. How about: Running a macro via SMS.

You get a Twilio account with a twilio number. Set up a ZAP which responds to a new SMS sent to your Twilio number and saves a file in a dropbox folder. Have the body of the message saved to the file. You have a macro which is set up on a new file trigger.

So when Macro Schedueler sees a new file in the dropbox folder it runs a macro, which reads the body of the newest file and then parses out the name of the macro it needs to run …

Now you can run macros remotely on your machine from your mobile phone via SMS 🙂

Load Testing – Measuring Elapsed Time

Filed under: Automation,Macro Recorder,Testing — Marcus Tettmar @ 12:02 pm

In a support email recently I was asked how to record a macro to perform load testing.

While you could certainly use the macro recorder for much of the process, in most cases you are probably going to want to insert some code to make the macro more dynamic in waiting for events to complete. Your load testing is going to slow things down and what you want is to measure how long things take. So you’ll need to be sure you’re waiting for “readiness” and calculating how long that took.

The macro recorder by its very nature records the firing time between distinct events like mouse clicks and keystrokes exactly as it happened at play back. It does however insert “WaitWindowOpen” commands when new windows appear and these will be dynamic – they will wait however long is needed for windows to open and close.

But more often than not you’ll want other forms of waiting. My personal recommendation is to use WaitScreenImage to wait for a visual cue on the screen. This is closely analogous to how a human uses the application – she uses her eyes to see what’s on the screen and determine “readiness”.

If you’re load testing then you’re probably going to run lots of macros – or virtual users – at the same time and are going to slow things down. This is exactly what you want to do – you want to see what the effect of adding more users is – and you’ll need to measure elapsed time. So you’ll need the macro to wait exactly as long as necessary.

The easiest way to do that is with Image Recognition. By all means use the macro recorders to record the simple bits – the bits that send keystrokes into fields. Or use the UI functions and the handy Find Object Wizard.

Also use the Screen Image Recognition wizard to record your waits. It’s real easy. Just capture the thing on the screen you want to wait for and it will spit out the code to do that.

So once you’ve done that you have a macro which will carry out the process and wait for things to complete and be ready before continuing. Now you will want to gather statistics to see what the elapsed times are and compare with different scenarios.

You might do this simply by looking at the log file for the macro. The log file outputs the time each command executed. So you could calculate the elapsed time between starting a step and when it completed. I’ve known customers simply open the log files in Excel and add their own formulas.

But I would make use of the Timer function to have the script itself measure the elapsed time of specific events. You might then output this elapsed time to an Excel or CSV file or store it in a database. It’s up to you.

Here’s a simple bit of code which sets a timer, runs Notepad, waits for it’s main window and then calculates elapsed time, storing it in a CSV file.

//start the Timer

//Run Notepad as an example
//wait for it to be ready
WaitWindowOpen>Untitled - Notepad

//How long did that take?

//elapsed is in milliseconds - write it to our CSV file

This is really just to show you how the Timer function allows you to measure elapsed time – you’ll likely have a bit more going on and if “readiness” is not signalled by a new window as it is here then WaitScreenImage might be a better option.

March 27, 2014

Why doesn’t SHIFT-ESC stop my compiled macros?

Filed under: Automation,Scripting — Marcus Tettmar @ 9:59 am

You might find that when you run a compiled macro and you also have Macro Scheduler running, Shift-Esc – the default stop key sequence – doesn’t stop the compiled macro.

This is because the stop key sequence is a system wide hot key. And system wide hot keys can only be registered for use by one application at a time. So if Macro Scheduler is already running when you start your .exe the .exe is unable to register Shift-Esc because Macro Scheduler already has it.

Of course when you deploy your .exe to people who don’t already have Macro Scheduler – which is usually the case – there won’t be any problem because Macro Scheduler won’t be running and so your .exe is able to register the Shift-Esc hot key.

But what if you want to define your own stop hot key, or you want to give your users the option of setting it? Well what you need is a KEY_DOWN event handler:

//CTRL-Z is stop key

//sample code here ...


Here we have set up a key down event handler for CTRL+Z. VK90 is Z and 2 is the modifier key for CTRL. See the OnEvent help topic and Virtual Key Codes List.

The event handler basically sets up a concurrent thread that is running all the while the main script is running. This allows it to respond to events such as this KEY_DOWN event. So when you hit the specified key sequence – in this case CTRL+Z, the doExit subroutine runs and all that does is call the Exit function which terminates the script.

You could be smarter and ask the user if he really means he wants to exit:

   Ask>Are you sure you want to exit?,ynExit

When you compile the macro there is an option to disable the standard Shift-Esc sequence. So you could do that to completely replace the stop key system with your own custom one using your OnEvent.

Consider an INI file and possibly another config script using a custom dialog to allow the user to set his own stop key sequence. Other apps could already be using it. My CTRL+Z example is probably not ideal as although it is used in Linux to suspend the current process it is usually the short cut for Undo in Windows.

March 17, 2014

Macro Scheduler 14.1 Available

Filed under: Announcements,Automation,Macro Recorder — Marcus Tettmar @ 12:18 pm

Macro Scheduler 14.1 is now available.

Here’s a summary of changes in Macro Scheduler 14.1:

  • New UI Automation functions for manipulating “Accessible” objects (UI Automation Elements).
  • New FindObject Wizard for locating objects, detecting accessible elements and outputting code to manipulate them.
  • Support for HTML email in SMTPSendMail
  • New HTMLViewer component for custom dialogs
  • Macro Recorder speed/reliability improvements
  • Other new functions and improvements.

The most notable addition here is the support for UI automation elements.  What’s this all about?

Well, this makes use of Microsoft’s Active Accessibility framework which allows application developers to expose UI elements to other applications.  It was originally designed to help accessibility tools like screen readers and also for automated software testing applications.

Essentially it means that the controls of applications – the UI elements such as buttons and form fields – can be more easily identified and manipulated.  Controls can be identified by name.  Here’s a short video showing this in use:

Bear in mind that what you can do with this will vary from application to application and what is possible will depend very much on what the application developer has exposed. If a developer hasn’t specifically named elements or knowingly used Accessibility, Windows will in many cases – and assuming a standard windows UI framework has been used – expose the controls anyway and will name objects based on their captions and labels.

To make it easy to identify elements we’ve added the Find Object Wizard which will show you the Accessible object beneath the cursor and let you create code to manipulate it (e.g. click it or set it’s value).  So using this you can experiment with what is possible with the application you want to automate.   Please let us know in the forums which applications you have used this with.

Assuming this new functionality proves useful, expect more features and improvements in future.

Trial Downloads | Registered Downloads | Version History

« Newer PostsOlder Posts »