« My Java Swing application has a lot of graphical interfaces, so it’s impossible to validate all of them by hand. Squish permits to increase the test coverage without increasing the duration of the validation, » said Vincent Laigle from SAGEM.
We had the pleasure to interview Vincent Laigle, the Validation Team Leader of SAGEM, who use Squish for their automated GUI testing effort of a Java Swing application. We talked about their test automation process and why they chose Squish over HP’s (formerly Mercury) Quick Test Pro.
Froglogic: Can you briefly describe the software you are testing with Squish?
SAGEM: It is a Java program which runs on an embedded Linux platform. It’s best described as a kind of mail software wich is plugged on a radio network.
Froglogic: How did you learn about Squish and when did you start using it?
SAGEM: I learned about it from Aptus. I asked them to search for a Java GUI test tool similar to Quick Test Pro but which runs also on Linux. After a successful evaluation of Squish we started to use it in June 2007.
Froglogic: What are the main reasons you decided to use Squish for your automated GUI tests? What are Squish’s main advantages over the competition?
SAGEM: Squish has several great features. Here is a list of the most important ones for us:
- It works well with Java applications using Swing/AWT (Editor’s note: Squish for Java also supports testing Java SWT and Eclipse RCP applications)
- The ability to modify and customize Squish’s object name generator to influence which objects’ properties to use for generating object names when recording scripts
- Built-in support for data-driven testing and data tables
Froglogic: Are you satisfied with froglogic’s technical support service?
SAGEM: Yes. The team at froglogic is very responsive and helpful!
Froglogic: What have been your biggest challenges in creating your automated GUI tests?
SAGEM: The software is sold on a kind of palm device with a touch screen. So there is no keyboard but a lot of graphical interfaces and elements.
Our customer often changes his opinion on the presentation of the interfaces. So I have to create test scripts wich can be easely adjusted in the future without the need to redo them for each change in the user interface.
Squish is very good for that: To abstract the test data from the test scripts, I use a lot of data tables. This combined with a few sed and awk scripts allows me to easily adjust the scripts to UI changes (for example to adjust properties in the object names) without the need to re-record the script.
This is something which is not possible with other GUI test tools like HP’s Quick Test Pro!
Froglogic: How many tests cases do you have approximately by now?
SAGEM: By now I have approximately 300 test cases with a total of about 9000 lines of script code and about 3200 lines of data tables. I’ve automated tests for approximately 30% of my application’s functionality so far.
Froglogic: Where do you see the main benefit of automated testing?
SAGEM: My application has a lot of graphical interfaces, so it’s impossible to validate all of them by hand. Squish (or automated tests in general) permit to increase the test coverage without increasing the duration of the validation process.
Froglogic: Is there anything else you’d like to add?
SAGEM: Squish for Java is a very good product, which is very customizable and adaptable. I had big problems with Quick Test Pro because the objects in my applications changing a lot. Quick Test Pro doesn’t permit to modify the object name repositories and generation in a good and automated way. Also it is not possible to easily edit the scripts outside their IDE.
As a result, with Quick Test Pro I had to re-record my scripts over and over again. Squish, on the other hand, permits me to use grep/sed/awk to modify my scripts and object map. Having a flexible tool like Squish saves a lot of time!
Froglogic: Thank you for your time!