What is UI Test Automation about?

In my last post I reviewed a tool for UI Test Automation for Silverlight. For those of you who have never worked on UI tests automation before I decided to explain what it's actually about.

The goal is to create a set of tests that would simulate user interactions with the interface. It's not only about manual actions like mouse click but also about visual verification of the expected result. Example: if a tester clicks a button and visually checks that it caused a message to appear you'd need to create at least 2 steps for that (covering the click and the message check).

The tool I described earlier this week offers an intuitive test recorder that integrates with Internet Explorer. It simply follows user interactions with the webpage and records each manual action as a graphical step. The visual verifications steps need to be added manually. This part requires more caution as it may be crucial for test results. A human would immediately spot an error message appearing on the screen. An automated test will only mark this test as failed if it contains appropriate verification step. Obviously the richer the app is the tricker it gets. A lot of visual effects (animation, popups, drag&drops) can cause you a serious headache ;)

Having a recorder available makes creation of basic tests much easier. Recorded actions are presented as graphical steps in your test project. They can be reordered, reused or combined with other elements (e.g. with if/else logic). More advanced tools offer data binding of the steps without writing any code. Example: let's say your test fills a form and submits it. While recording you provided some data but would like to retest the scenario using different data sets. If you data-bind the test you'll be able to re-run it automatically for each dataset available in source. Available data sources differ between tools but most popular ones are database, excel spreadsheets and xml files.

Although recorder and graphical steps make it easier to start with basic test I found myself creating most of the tests in code. It is possible to convert each graphical step into a coded step as well. This give you more control over the test. Some functionality is usually only available via code because it is almost impossible to implement all the possibilities offered by a programming language in a graphical tool. I can't imagine creating a complex test relying only on options offered by graphical steps. This may be a serious problem for testers with no programming experience.

In my next post I'll try to provide some tips & tricks that I learned while working on UI Test Automation.

PS. The provided examples are usually related to web applications. This is because I mainly work on such apps. However, all the rules mentioned above also apply to desktop applications.