Automated GUI Testing: Meeting Us Halfway
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)
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.
One piece of advice: keep your test code in at least two layers of abstraction:
- upper layer: this should be some sort of a facade that is oriented towards your specific application terminology/actions etc. This layer does not directly use the Selenium RC library. In the background it uses the...
- ... lower layer: a library with some common testing patterns (example: "assert that the value X of the radio button control is chosen"), which uses the Selenium RC library.
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.