Automa Blog

Happy New Year 2015!

We would like to wish all our users, fans & customers all the best in the New Year. We hope 2015 will be prosperous for everyone! In particular we would like to wish you many successes in the field of testing & automation, hoping that our tools can help you achieve what you need.

Happy New Year 2015

Automa 2.7.0: press_and_hold

We're happy to report that Automa 2.7.0 has just been released. Besides some small bug fixes, notable new features are the commands press_and_hold(...) and release(...). These two commands can be combined to press, hold and release keyboard keys. For example, the following snippet starts the Chrome web browser and zooms in using the mouse wheel, by pressing and holding the CTRL key:

start('Chrome')
press_and_hold(CTRL)
scroll_up()
release(CTRL)

Support for these commands was added because our users and customers requested them. If you would like to request a feature, please let us know via our contact page. (Priority is given to paying customers.)

The new version can as usual be downloaded from our download page. Happy automating!

Welcoming our latest customer: Esri Inc

Logo of Esri

We are happy to announce that after renowned companies like Intel and Samsung, we have another global specialist as one of Automa's customers: Esri specialises in GIS solutions. Esri connects governments, industry leaders, academics, and nongovernmental organizations with the analytic knowledge they need to make critical decisions that shape our planet.

If you have not tried Automa yourself yet, we encourage you to give it a go! It's so simple, everybody can do it. Simply go to our download page, fill in your details and click Download. You will receive a Windows executable which you can immediately run, without prior installation.

Happy automating!

Automa 2.6: Improvements

After a small break over the (European) summer, we're happy to report back to you with a new and improved version of Automa, 2.6 :-)

The first significant improvement in Automa 2.6 is that playing back files has become significantly easier. Previously, scripts which you had saved with a .at extension had to obey the exact same syntax rules as when you typed the file into the interpreter. For example:

notepad = start('Notepad')
if MenuItem('File').exists():
    print 'All good!'
 
kill(notepad)

Do you notice the extra, empty line after print 'All good!'? This used to be required because when you type in the above script in the Automa console, you needed to confirm with an empty line that you want to close the if block:

>>> notepad = start('Notepad')
>>> if MenuItem('File').exists():
...     print 'All good!'
...

This makes sense in the interactive interpreter (because otherwise it has no other way to know whether you are done with the if block), but for a saved .at file where the next lines are known, it was sometimes very confusing. That is why we changed it so you can now write

notepad = start('Notepad')
if MenuItem('File').exists():
    print 'All good!'
kill(notepad)

in your .at scripts.

In the process of improving Automa's playback capabilities, we also improved its error reporting. When there is an error in a script and you try to play it back using Automa, it now gives you more detailed information about where the error occurred. Another issue pointed out to us by some of our users is that when you ran a script with an error by opening it with Automa.exe, then the Automa console window used to close too quickly for you to be able to read the precise error message. We also fixed this so that the error is displayed until you explicitly close the console window.

Finally, Automa 2.6 adds support for the latest version 36 of the Google Chrome browser.

Happy automating!

Welcoming UC Berkeley as Automa's latest customer

Logo of the University of California, Berkeley

After high-profile companies like Intel and Samsung, we are very proud to announce that we now also have the highly-renowned University of California, Berkeley as one of our customers.

UC Berkeley are using Automa to automate the testing of some applications developed in-house. The fact that Automa is so lightweight and does not require installation makes it very easy to integrate into Berkeley's existing infrastructure.

For a selection of some of Automa's other customers, please visit our home page (scroll down for the selection of customers).

Taking screenshots with Automa

We're happy to announce that we just released version 2.5.5 of our next generation GUI automation tool, Automa. Besides a few small improvements, the new version features a command called save_screenshot(...). This command lets you save a screenshot of your entire screen contents to a file. This is very useful for debugging or further processing of the outcomes of a test / automation run.

The syntax of the new command is very simple. You merely pass a string identifying the path of where the screenshot should be saved. Automa saves the file as a PNG file, so we recommend the file ending .png. For instance:

save_screenshot(r'C:\screenshot.png')

Please note the leading r before the quotation mark in the example. This is always required when working with file paths as it instructs Automa's built-in Python interpreter to treat any backslashes in the string as plain-text backslashes (not, as normally, as escape characters).

After playing around with the new command ourselves, we found it surprisingly useful and fun to use. We hope you will feel the same. You can as always download the new version from our download page.

Happy automating!

Automa now supports Python 2.7.6

Python 2.7.6

After comprehensive regression testing, we are happy to announce that we just released a new version of Automa. Besides some small bug fixes and stability improvements, this release adds support for Python 2.7.6, the latest version in the Python 2.x series. You can download the Python 2.7.6 installer here and the latest version of Automa from our download page.

Happy automating! :-)

Uninstall programs automatically

Automa can be used to automate repetitve tasks such as uninstalling programs. Take a look at the script below:

import sys
assert len(sys.argv) > 2
press(LWIN + "r")
write("control.exe appwiz.cpl")
press(ENTER)
click(sys.argv[2])
click("Uninstall")
click("Yes")
uninstall.at

In order to run this script and uninstall an application run:

>Automa.exe uninstall.at "Name of the application"

The Bug Hunt Game at EuroSTAR 2013

Update 05/11/2013: The Bug Hunt Game will take place on Wednesday, Nov 6 in the Community Hub at EuroSTAR. Come find us!

As explained in a previous blog post, we won two places for this year's EuroSTAR testing conference in Gothenburg, Sweden. We can't wait to attend this great event, and have prepared a special game for the other attendees, to let them relax, have fun and meet new people.

The rules of the game are the following: Each player is either a "bug" or a "bug hunter". Players receive badges that show which of the two they are. When a bug and a bug hunter meet, they play rock paper scissors. The winner takes one of the other player's lives. A scoreboard will be kept and at the end of the day the winner (ie. the person with the most lives) will be announced. We're curious to see whether it will be a bug or a bug hunter!

The game was developed during a workshop by Oana Juncu at Agile Testing Days 2013, in close collaboration with Jesper Lottosen (@jlottosen on Twitter).

The game will most likely take place on Wednesday or Thursday. You can sign up for it in the EuroSTAR Community Hub. We will publish further details here and via our Twitter account.

See you at the conference and, as always, happy automating! :-)

The number one rule for dealing with unstable builds

We'll soon have some pretty revolutionary news for you. While we're working hard to make them happen, here is a little post for you with our experiences of how to best deal with an unstable build.

Suppose you have a build that passes most of the time but fails with irreproducible errors every so often. Maybe the build accesses an unreliable service, or performs some automated GUI tests that are not as stable as they should be.

The next time the build fails, do not simply run it again. This is worth repeating: Do not simply re-run a broken build in the hope that it will magically succeed.Yes, you are just working on something else and really don't have time to deal with this instability now. But if you ignore instabilities like this too often, you start going down a very dangerous route.

Every time the build fails, you are given the unique opportunity to fix one of your build's (or even software's!) instabilities. This is great! You get to experience first-hand how a bug that will most likely affect your users manifests itself. Now is your chance to fix it. If you simply re-run the build, you will most likely lose valuable information, such as log files.

If you make it a habit to simply re-run the build when an instability occurs, it is likely that more and more instabilities will sneak into your program. The failing builds cost you more and more time, and you feel even more like the last thing you have time for is to fix the occasional failing build. A vicious circle.

If you really don't have time to investigate an instability when it occurs, at least make time to save all information such as log files that might give you a clue as to what caused the problem. Once you have completed your pressing, pending task, go back and investigate what caused the build to fail.

Sometimes when an instability occurs, you don't have enough information to find out what caused it. Do not take this as an excuse to ignore the instability. Add more logging that might let you find out what the cause of the problem is the next time the instability occurs.

One approach we have had very good experiences with was to keep logs of when each particular instability occurred. The problem with an instability is that, since it is not reproducible, it is often not possible to test whether an attempted fix actually works. If you have logs of when the instability occurred, you can estimate roughly how often it occurs (eg. once a week, or on every 10th build). If after your fix attempt you then don't see the instability for two weeks or 20 builds in the previous example, you can be pretty confident that your fix attempt was indeed successful.

We'll be at the Agile Testing Days in Potsdam, Germany tomorrow. If you see us around, do come and say hi!

Happy automating! :-)