.webp)
Specsavers Optical Group is Britain’s most trusted optician*, used by more than 7.6m customers in 2011. Specsavers originated in Britain and now has more than 1,600 stores throughout the UK, Ireland, the Netherlands, Sweden, Norway, Finland, Denmark, Spain, Australia and New Zealand. Specsavers has developed a considerable amount of in-house software to support its business—this software is tested by Specsavers’ own in-house testing team with support from SQS, a consultancy that specializes in software testing and software quality.
We spoke with Specsavers’ Testing Services Technical Test Manager, Tim Collins, and with one of Specsavers’ SQS consultants, John Alexander. Tim has been involved with software testing for over four years, and John in testing development and leadership roles for around seven years. John has had direct experience of several testing tools including QTP, SilkTest, and Selenium.
Background
Specsavers employs more than 26,000 people worldwide. SQS employs about 1,000 consultants in Europe, 500 in India, and smaller numbers in other countries. One of their specialties is testing other companies’ software and developing testing solutions for other companies to use.
Specsavers has a large portfolio of in-house applications, with plans to roll out Squish testing to 50 application variants. Currently, Specsavers is using Squish to test three of these applications: SOCRATES, Solar 7, and Connect.
Specsavers’ SOCRATES application uses Java and Web technologies to manage customer details, including customer registration, appointment management, sight testing, prescribing and ordering eyewear, and collecting payment. Solar 7 is a Java and Web based laboratory management system that handles the ordering, creation, and shipping of lenses. Specsavers also have an intranet system called Connect that is wholly web based.
Why Squish
Specsavers had many requirements for its testing process. The client wanted a testing framework that would work with HP’s Quality Center (QC)/HP ALM 11 and that would work with Linux. The framework would have to support the testing of Java and Web applications on both Linux and Windows platforms. In addition, the framework would need a GUI testing tool that could be fully integrated with the framework and with their workflow. For the GUI testing tool itself the client wanted to be able to have staff with no scripting experience be able to specify tests by entering data into spreadsheets which would then be used to drive GUI tests—a classic example of a keyword-driven testing approach.
Specsavers commissioned SQS to develop the testing framework. SQS had not used Squish prior to this project, but discovered Squish when searching for suitable GUI testing tools that they could integrate with the framework they were building. SQS evaluated Squish in competition with a pre-existing in-house developed tool, and with LDTP (Linux Desktop Testing Project), Selenium, SilkTest, and IBM’s Rational Functional Tester.
Squish was chosen above the others for several reasons. These included: Squish’s easy record and playback functionality to quickly capture test steps and test objects; Squish’s HP QC/HP ALM plug-in; Squish’s runner/server architecture; and Squish’s support for multiple GUI toolkits. John also mentioned froglogic’s good customer support and Squish’s competitive pricing as being additional contributing factors to Squish’s adoption.
Squish in Use
Currently, Specsavers’ has developed around 2,000 test cases for SOCRATES, of which 200 are Squish tests. For Solar 7 there are 1,500 test cases, 100 of which use Squish. The client’s Connect software has 500 test cases so far, with new Squish-based tests in the pipeline. All these Squish tests use JavaScript. (Currently, Squish tests can be written in JavaScript, Perl, Python 2, Ruby, or Tcl.)
John said that they had had some initial problems with hooking Squish into their applications, which had soon been resolved. They needed to do some unusual tasks, but found that Squish’s extensive APIs provided what they needed. They also make great use of the Squish Spy to examine application objects, and they edit the Object Map to provide more user-friendly names for the objects that are used in the spreadsheets. (Squish’s Object Map is a mapping between object names used in test scripts and object properties—excluding volatile ones like coordinates—that provides robust object identification even in the face of application changes.)
When we asked John about froglogic’s technical support he said:
“It’s very good. A good working partnership is crucial to inspiring confidence with the client, so that issues can be overcome.”
Conclusion
Specsavers and SQS have developed a keyword-testing-based framework that allows testers with no scripting experience to create GUI tests simply by populating a spreadsheet with data. The spreadsheets are uploaded to HP QC/HP ALM from which the tests are run and the results accumulated. This system has lowered the bar for testers to be able to test Specsavers’ in-house applications and has significantly improved test reliability compared with earlier approaches.
Tim told us that Squish, along with their testing framework, had allowed them to create test automation that was both economic and ensured high levels of quality. Of froglogic’s support, Tim said:
“It’s extremely good. Very helpful and a fast turnaround for fixes.”
Specsavers’s Squish and HP QC/ALM-based testing framework has proved such a success that the original plans for the testing of just 3 applications have now been extended so that eventually 50 important application variants will be tested using the framework.
froglogic’s team would like to thank John and Tim for taking the time to share their teams’ experiences with Squish, and we looking forward to a continued successful relationship.
*Specsavers was voted Britain’s most trusted brand of opticians for the tenth year running by the Reader’s Digest Trusted Brands survey 2011.
