Marcus' Macro Blog
This is a guest post by Antonius Momac and Jana Krawiec, QA Automation Analysts at Triple Point Technology.
“If you don’t know where you’re going, any road will take you there”
- George Harrison
The main questions to ask when considering automated software testing are: “Where do I start?” and “Where is it that I want to go?” If you spend too much time on the wrong path, you’re either going to fail or overspend on time and resources. Therefore it’s a good idea to get a clear picture of how information systems (applications under test) work. I don’t mean at the low-level of zeros and ones that are crunched by the CPU, but rather where human meets machine.
The fundamental to any software process is that there are three main parts:
the Input (start), the process (main action), and the output (end) . From the input, some data is taken and changed by the process which generates the output; i.e. modified data.
As an automation engineer, the choice of what part of the process to automate is yours. Automate as much or as little as you see fit. Think about your particular situation and what makes sense. Do you automate the setup? Or is it better to automate the steps of the test plan (the driver/autopilot) and/or the verification? Better yet, all three, or just one of them?
We started with a manual test plan and fully automated it. Simply because the Macro Scheduler scripting language is flexible enough to support automation from all approaches. Automating the setup, the input, the process (say clicking on a button, or some mouse actions), as well as the verification of the output and reporting went smoothly. We created small scripts that were managed from a master script. A full and complex four hour test plan was built. Everything worked great until we put it to the action testing a new build. We discovered that our GUI is in constant flux, which caused major changes to wreak havoc on our automated scripts. Real time maintenance of scripts was required, thereby slowing down the entire testing process. Ironically, this is the exact opposite of what test automation is all about.
In the end, full automation didn’t work for us. Less technical minded testers were not interested nor capable of learning how to debug a failing script. Moreover, with the introduction of new features and constant GUI changes, our major focus during testing went to maintenance of our automation routines instead of finding bugs in the new release. Knowing that we picked the best possible software for automation allowed us to start looking for alternative approaches. We decided to bypass the GUI interaction and focus on the verification process, since we never experienced issues with it. Before long, we were getting through the testplan faster by manual GUI interaction combined with the verification process. It allowed us to test the application quickly, accurately and in depth. Once we got the best of both worlds, we decided to develop a tool that would handle the verification with minimal setup. With this tool anybody could set it up and get right into regression testing and finding bugs faster. It allows us to integrate automation into new test plans very quickly.
Let’s analyze a test plan of 156 US-Letter size pages in length to get a better understanding. The Majority of the test plan, 125 pages (82.6%), are dedicated to verification or what we call a checkpoint. Further breakdown of those 125 pages revealed that there is 1 verification process is being repeated 50+ times consuming 108 pages. Manual verification is tedious and time consuming. Automating this one repetitive process eliminates 70%(108 pages) of the entire test plan in one shot.
Best of all removing, adding or updating automated routines proves to be an efficient process. No need to reconstruct or redesigning existing scripts and routines, saving us plenty of valuable time with minimal maintenance. Clearly, this is the road anybody wants to be on when it comes to automating your test plan.
So when you’re thinking about automating your test plan, consider these three rules of thumb:
-
What needs to be automated – Any fixed and repetitive processes where automation will save time, and ensure accuracy. Big wins equal huge time saving with little code.
-
What can be automated – depends on the tool you’re using, since Macro Scheduler can be used to automate any process, be careful. Automate, but automate wisely… Your milage may vary.
-
What should never be automated – pieces that require excessive time and resources allocated disproportionately to the amount of time saved (mostly from maintenance point of view). Maybe your test plan needs to be reworked.
Remember Bill Gates quote: “…automation applied to an efficient operation will magnify the efficiency. …automation applied to an inefficient operation will magnify the inefficiency.”
Contact the authors:
Our good friend Antonius Momac just emailed me to tell me about this video he has put together on automating test plans with SQL verification:
Macro Scheduler users will probably recognise that Antonius is using Macro Scheduler to drive these tests [ keep an eye out for the Macro Scheduler icons and custom dialogs 
]
Dorian has just uploaded a video demonstrating his Screen Capture and Email script. Nice video, check it out:
Congratulations to Rain for winning last month’s Script of the Month entry. Rain won for his nice little Zipfile Script.
He wins a custom MJT Mug:
Want to win a custom mug? Well then, get posting. Contest details here.
Someone asked today how it might be possible to paste what is in the clipboard into an object using Macro Scheduler without having to use keystrokes.
It can be done by sending the WM_PASTE message using the SendMessage API function.
Here’s an example:
//Sending WM_PASTE to an object causes a clipboard paste, like sending CTRL-V //constants - here we define the WM_PASTE constant Let>WM_PASTE=770 //we need the handle of the object we want to send WM_PASTE to - // - as an example let's find the handle of Notepad's edit window // - for this example make sure Notepad is running with empty document // - so that the window title us "Untitled - Notepad". Modify if needed GetWindowHandle>Untitled - Notepad,hWndParent FindObject>hWndParent,Edit,,1,hWnd,X1,Y1,X2,Y2,result //now send WM_PASTE to it using SendMessage API LibFunc>User32,SendMessageA,result,hWnd,WM_PASTE,0,0
The only benefit I can see with this is that it doesn’t require keyboard focus. In theory neither should ObjectSendKeys and a CTRL-V require keyboard focus. The latter is simpler so I’d tend towards using that. And there may be some applications that work at a higher level and actually expect to see CTRL-V or similar.
Never-the-less it’s a nice example of sending a Windows message and it may be useful for some. So here it is.
In this post from 2008 I demonstrated how to get data from Excel worksheets using Macro Scheduler’s database functions.
This works fine if Office is already installed on the PC. But what if you want to get data from an Excel sheet and the PC you are running on doesn’t have Office installed?
Well you need the Office Data Connectivity Components which you can download from microsoft.com here:
http://www.microsoft.com/en-us/download/details.aspx?id=23734
This will install the OLEDB/ODBC drivers which DBConnect can then use to make a connection to a workbook. You can then use DBQuery to retrieve data from a sheet as shown previously.
Each month we will choose our favourite script or video posted to the forums and send the developer an MJT Net Gearhead mug. *
Your entry may be something submitted in the usual course of events – i.e. as an example or in response to a user’s question, or just because you want to win a nice mug!
We’ll accept either some script code or a video demonstrating an automation routine running on your systems.
Any script code you submit needs to be something that will run anywhere and not dependent on applications that only you have access to! If that isn’t possible, post a video instead.
Your script could be an example of some neat bit of code, something useful for others or just a bit of fun. Ideally it will demonstrate something that others can learn from.
As mentioned, we’ll also accept a video or screencast if you have a cool script you want to share which only runs on your systems. So, for example, if you have a routine running at work which automates a desktop or web app that can’t be shared, then take a screencast of the macro in action, submit it to youtube or vimeo or similar and post a link on the forum.
So, get your thinking caps on, and send in some cool code or a macro movie.
* Ideally, each month, we will choose a script/video posted the previous month, but we reserve the right to pick a post submitted at any other time (especially if there have been no recent entries). We get to pick our favourite – whatever that may be
Our good friend Antonius Momac has put together this great video tutorial series.
In this series Antonius walks us through how to use Image Recognition to find and click on a bunch of check boxes. As well as how to use Image Recognition, these videos show you how to loop through an array and how to create subroutines to make your code more efficient and reusable.
We have more video tutorials here. If you have an idea for a new video tutorial, please let us know.
Here’s a quick video showing how easy it is to use Macro Scheduler‘s image recognition to control a Linux Desktop (Ubuntu in this case):
Pages
Archives
Categories
- Announcements (205)
- Automation (98)
- General (195)
- Podcasts (5)
- Scripting (127)
- Success Stories (12)
- Testing (12)
- Tutorials (5)
- Uncategorized (18)
- Vista (24)
- Web/Tech (15)
- Windows 7 (7)
- Windows 8 (2)