Some of you may be wondering why Green Hat has decided to add GUI testing into our GH Tester suite of tools for testing SOA and integrated systems. There are several answers to this. Firstly, when I was out and about meeting customers, I found increasing numbers of them had been using GH Tester with their existing GUI automation products. Why were they doing this? Surely there are not many humans in an SOA world? The answer lies in the fact that much of the ROI from an SOA is currently coming from Business Process Management (BPM). BPM models the existing human processes, but as the project evolves, the BPM processes are used to extract information out of key systems, nowadays using an SOA (see figure 1).

Once all the information has been gathered up, it can be presented to a human being who can then make a decision on it (the value-add bit), rather than wasting their time collecting the necessary information from disparate systems to make that decision (non value-add).

So why is testing different and difficult in this world? Simply because to test the BPM process, all the underlying interfaces and static data needs to be set up. Not only that, but if a rich GUI has been developed over the top of the BPM platform, or you are using one of the AJAX toolkits offered by people like TIBCO and Software AG, you need to test that GUI. Unit testing is difficult without the systems that the BPM process will call. Enter GH Tester with its new GUI testing capability. GH Tester can not only automate the GUI based system but can simulate the underlying dependencies, allowing different paths of the GUI to be tested without needing to hard code this into the application under test (figure 2).

Some people call this service virtualization. At Green Hat, we like to keep things simple and efficient, so we call this stubbing. This allows unit testing of the application to be completed whilst the services are still being developed, extending the revolutionary way that GH Tester helps your end-to-end testing all the way to the humans too.

So why is this an improvement on the way our customers are doing it today? Firstly, although existing customers are using combinations of HP QTP with GH Tester, it is time-consuming to set up from the existing GUI automation application and the results we are able to pass back are limited by the vendors of these applications. This means there are multiple places you must look to understand what went wrong and where: not good.

Secondly, data driving these tests in and out of the GUI and back and forth from GH Tester was made impossible by the extension points offered by these vendors. This meant that the tests did not scale well when customers wanted to try many different scenarios driven by Excel or a database or other data source.

Thirdly, some green field sites that are not doing GUI testing but are interested in the intuitive, codeless approach that Green Hat took and wanted to know if we offered GUI testing, so now we do!

We hope you find the new GUI testing capabilities useful, we’ll be posting a video of the functionality in action shortly, watch this space, and if you’d like a demo before that, please get in touch.