Apply the above process repeatedly for the different Web methods on the WSDL, and ultimately you'll have a complete test case for a specific WSDL. Test cases can, in turn, be gathered into a test suite, which is really just a kind of folder in the LISA environment.

Click for larger view.

LISA provides a healthy collection of test step types, though in most test cases, the majority of steps are of the "Web service execution step" type: Send a request, examine the response, and determine success or failure. Other step types can verify a Web service's compliance with various standards, execute external Java classes, or even call command-line scripts.

In addition, each test step can be adorned with a variety of filters and assertions. The former is provided to parse the content of response messages. For example, you might apply a filter to fetch a specific response value and store it in a property for use in later steps. The assertions manage verification of response data, WSDL, and message conformance. Also, the assertion section of a step specifies whether it has passed or failed, and it identifies whether execution control should proceed to the next step or to some other step.

The full LISA product is very Java-aware. It can generate JUnit tests, functional tests of Java classes, database tests via JDBC, and EJB tests. The free version, WS-Testing, is limited to generating only test cases and for Web services only. In addition, some test steps types are unavailable (it lacks any J2EE-related test step types, for example).

For all the initial ease of learning LISA, navigating the UI is sometimes bumpy. For example, when entering a new value for a field in a test step, there is no obvious way to save that value, nor to cancel the change. I found the only way to cancel input was to select a different node in the explorer, then dismiss the dialog that asked if I really wanted to do that.

The LISA documentation makes a big deal of no-code test development, as if that is the high road to simultaneously simplifying and accelerating test development. Perhaps, but while LISA's pure UI-approach does have the benefit of live interaction and is more accessible to QA engineers inexperienced at coding, it has limitations that a tool with easier access to scripting does not. Some testing nuts can only be cracked by a well-sharpened piece of code.

Mindreef SOAPscope Server 6.0
SOAPscope Server, like QEngine, is a thin-client-based tool. Behind SOAPscope's browser UI is a Tomcat server, girded by an RDBMS (relational database management system) that can be MySQL, Oracle, Microsoft SQL Server, or the embedded Apache Derby database. (Derby is supplied with SOAPscope but not recommended for even moderately large installations.)

SOAPscope Server's service spaces are the overarching containers of testing assets. An administrator will use service spaces to organize users into groups. Within a service space, member users can create one or more workspaces in which to store their, well, work.

Inside a workspace you'll find WSDL contracts, tests, notes, and other ancillary material needed to support actual testing. Typically, a workspace corresponds to a WSDL: When you create a new workspace, the first prompt you encounter is for a WSDL URL. You can, however, add more WSDL contracts to the workspace once it is created. Once you've imported a WSDL into a workspace, you can begin adding messages to that workspace. A message is really a SOAP request/response pair, created when you invoke a Web method on a WSDL. The invocation also optionally creates an "action" within the workspace.