Perhaps it’s just our preoccupation with new development, but it never ceases to amaze me how little attention is paid to the entire application lifecycle. This seems especially true whenever a new technology is introduced and assimilated. Consider Web services, for example.

There are countless books and seminars, primarily targeted to the developer, focused on the design and coding of Web services and service oriented architectures (SOA). Yet, precious little information is given to the latter phases of the application lifecycle, such as the testing, deployment and management of Web services-based architectures. In this column, we will tackle the unique challenges surrounding just one of these phases - the testing of Web services, particularly as it is applied in an inter-enterprise SOA model.

Before delving into Web services testing concepts, let’s explore the unique aspects of Web services that present a challenge to traditional testing models.

There are three key aspects to Web services used in SOAs that are worthy of mention.

First, a Web services-based architecture results in a distributed, loosely coupled system with dependent stakeholders.

While this architecture holds great benefit in terms of scalability and extensibility of the system, it poses a great challenge for the tester. No longer is each component of the system necessarily constructed and deployed by a single corporate entity. Potentially, the overall system may actually be derived from components that are constructed, tested and hosted by multiple stakeholders. As such, it is difficult to establish consistent code quality, availability and quality of service (QoS) across these entities.

The second difference in the Web services solution is that it provides a standards-based, service-driven model to integration. While prior object technologies such as CORBA provided facilities for building distributed architectures, they did so via complex programmatic interfaces. With Web services, standards for data format (XML), communication (SOAP) and programmatic interface (WSDL) are data-driven, simple and share a common XML-based foundation. Traditional testing tools must evolve to fully support these standards for effective testing to occur, but that hasn’t really happened yet.

The use of Web services standards also offers other implications to current testing tools. Web services-based integration highlights the importance of validating interface points and message formats rather than simply testing at the graphical user interface level. Using testing tools that utilize GUI-driven automation is simply inadequate for a Web services project.