Menu
I've been tasked with developing a system for automated GUI testing and I could use some advice. As luck would have it, we are in the midst of a major redesign of our GUI and the developers doing the work are open to making their code more friendly to automation. My problem is that I'm not sure what to ask them to add. Whatever hooks are added can't impact the functionality, appearance or security of the interface and shouldn't have a noticeable impact on performance. Other than that, the sky's the limit!
The application in question is a web-based Java app accessed via AJAX. Most of the existing features are coded using jsp, Javascript and a little bit of Flash 8. The next wave of features will be done using the YUI Javascript library. I'm pretty much settled on Selenium as a test tool because of its flexibility and price tag (free). Major point: I'm aiming for test-reusability and ease-of-maintenance. My preference is to write code that detects, validates and exercises the page elements rather than use a record-and-playback system for test development.
Can anyone provide some guidance as to what hooks could be placed in the code or some best practices to make test development easier and the tests themselves more robust?
409
GUI automation refers to automating the testing of an application via the graphical user interface (GUI). The main advantage of this type of testing is that the application can be tested in the way it’s used by the user. It also doesn’t require the source code.
Apart from ensuring that back-end and the front-end code are properly connected, here are the most common features of automated graphical user interface testing: Testing the interface from the user’s perspective. Conducting GUI testing, you’ll be able to try out the most popular scenarios of user behavior on the website.
There are two ways to deal with GUI testing – manually and automatically. In this post, we’ll be explicitly covering the second strategy. Who Needs GUI Testing? Most development projects use a layered architecture approach. What a developer sees as a whole of data coverage and business component is wrapped for a user as a graphical user interface.
Creating a separate module for an automated GUI test framework allows you to connect the same script to different projects in case you want to test several websites or apps simultaneously.
Basic guiding principle: if they want you to test something, testers need a way to get the application into that state, and once in that state, a way to validate that the state is correct.
So the first thing is to ensure they understand that automation is programming and the UI is your API.
Agreement to not arbitrarily change the UI -- if tester Bob see that the component changed from a button to a link, and it matches the spec, clicks and goes on. While a relatively easy code change in automation, it is a change that may have to be made in multiple locations. (your job as a tester is to understand that change happens and minimize the cost of maintenance; their job is to only make important changes and to understand the impact)
A way to determine which page you are on.... Bob can tell the difference between login and order entry, but how will automation know? If an enter field with the 'Username' label, the login page. If an entry field with Order number, the order field.
Not good -- better practice is a consistent UI element to identify the page -- page title, hidden component, etc.
A way to uniquely identify every element that you need to interact with (click, type in, verify, etc.) And not INPUT_42....
Ask the developers what information that testers can provide them to speed their debugging, and ask them to put it into a log file
Ability to dump state of the program
Consistent error handling & reporting (also just good UI design)
107
As with most questions, it depends. Mostly on what your site looks like and what sort of controls are on the pages - are there a lot of repeated elements etc?
I've had a lot of success using Selenium RC and Selenium IDE. The main thing is getting used to using Selenium and its commands. It's also helpful to get used to locating objects on the page (XPaths and CSS selectors, as well as 'contains' function). What you don't want is a lot of elements that have the same select path. If the tables and divs below don't have a unique part to them, it can add extra complexity to your tests.
<html>
<body>
<table>
<tr>
<td>
<div></div>
<div></div>
<div></div>
</td>
</tr>
</table>
<table>
<tr>
<td>
<div></div>
<div></div>
<div></div>
</td>
</tr>
</table>
</body>
</html>
To test images, its nice to be able to check for their existence based on something other than the image file name, so you don't have to change your tests when the image is updated. If you need to test Flash objects, check out this site.
Beyond that, there isn't a whole lot that I have noticed that can be incorporated in the development side. Once you start setting up the tests and locating elements on the page, you'll probably see pretty quickly what the developers need to do to help you out.
40
One piece of advice: keep your test code in at least two layers of abstraction:
This way your tests will be cleaner to maintain and more understandable in terms of what is being tested. We even tried a three-layered approach, the third (uppermost) layer being the tests specified using XML. This was in order for our non-programming testers to be able to specify acceptance tests without delving into the C# code.
28
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
