SoapUI is useful to QA when integrations center on SOAP, WSDL, XML, and sequences of service calls. It exposes messages and contracts at a level that the UI rarely shows. For example, a "Create contract" button may hide several SOAP messages, namespace checks, and SOAP Fault handling. Verifying that chain requires understanding the message itself, beyond seeing a successful HTTP response.
How WSDL, SOAP, and a project relate
WSDL describes a service interface: operations, messages, bindings, and addresses. XML Schema defines data structure and constraints. A SOAP envelope contains administrative and substantive message sections. Importing a WSDL into SoapUI helps generate requests, but a template is not yet a working test. It may contain question marks, optional elements, or an unsuitable address. QA checks dependent XSD currency, the contract version, and test endpoint settings.
The TestSuite, TestCase, and TestStep model
A project contains settings and test suites. TestSuite groups scenarios, TestCase describes an executable sequence, and TestStep performs an individual action: sending a request, storing properties, transferring a value, or executing a script. Assertions evaluate responses. This separates a clear business scenario into diagnosable steps. If identifier retrieval fails, a subsequent contract retrieval should not appear to be an independent service defect: investigate the original failure first.
SoapUI and ReadyAPI: understanding the boundary
Documentation includes examples for both SoapUI and ReadyAPI. Some steps, particularly advanced DataSource/DataSink steps and related features, belong to ReadyAPI. A feature mentioned in a guide is not a promise that every installed edition supports it. Record your team's product, version, and actual available execution method. Starting with one request and a meaningful assertion is more useful than designing a complex architecture around an unavailable component.
What to prepare before the first request
Obtain a current WSDL with all dependencies, a test address, an authentication scheme, and an example of valid business data. Clarify date, encoding, and reference-data restrictions separately. XML valid against an XSD can still contain a nonexistent department code or a contract in an invalid state. Confirm that the test environment does not send real documents to customers. For certificate-based services, also establish who issues test credentials and how trusted certificates are renewed.
Exercise: create a contract and retrieve it
Suppose CreateContract accepts customerCode and amount and returns contractId, while GetContract returns the contract state. Requirements specify that amount is a decimal with a minimum of 0.01 and that the currency is fixed. Creation uses a test customer, and subsequent retrieval must confirm the saved amount. First agree on these expectations with the product contract; the field names in this example are illustrative.
- 1.Import the WSDL and check each request's endpoint. Supply a valid test customer and amount=100.50; expect business success with an identifier.
- 2.Add assertions for the absence of an unexpected SOAP Fault, a correct response structure, and a nonempty contractId. Checking only that "the response contains a number" is insufficient.
- 3.Use Property Transfer to copy contractId into a TestCase property and use it in GetContract. Expect the same customer, amount, and initial state.
- 4.Repeat creation with amount=0 and with customerCode missing. Expect the agreed errors, and verify that no new contract was created.
- 5.Reset the temporary identifier and repeat the scenario. After CreateContract fails, retrieval must not use a contract from the previous run.
Properties and value transfers
Project properties suit shared nonsecret settings, TestSuite properties suit suite parameters, and TestCase properties suit data for a particular sequence. A reference such as ${#TestCase#contractId} substitutes the property value into a request. Property Transfer extracts a response value and passes it to the next step. For XML, account for namespaces: matching local element names does not prove that XPath selected the correct node. Check extraction against empty and error responses.
Groovy can generate dynamic data, but avoid hiding the entire scenario in one long script. An explicit transfer and a separate structure check are usually easier for someone investigating a nightly failure to understand. If a prerequisite is unmet, a script should fail clearly instead of replacing a missing identifier with a random string and continuing.
Assertions at multiple levels
First check transport: whether a response arrived and whether HTTP behavior matches the agreement. Then check SOAP: success or an expected Fault, the correct operation, and the namespace. Next check the schema and business values. Errors do not all use the same HTTP code, and the absence of a Fault alone does not establish success. Comparing XML as a plain string is fragile: namespace prefixes and formatting can change without changing meaning.
Also consider consumer behavior when the contract changes. If an optional response element is added, test an older client: a strict deserializer may reject the message even though the new schema appears compatible. For financial values, compare decimal meaning and specified rounding rather than whitespace in XML. If the server returns a date with an offset, check its interpretation in the agreed time zone. These checks go beyond simple XSD validation, but often determine whether an integration remains functional after release.
Negative checks and diagnostics
Useful cases include an unknown customer, an amount above the limit, an invalid date format, a missing required element, and a repeated operation. Separately explore the differences between an absent element, an empty value, and xsi:nil when the schema permits them: the server may handle these states differently. On failure, preserve anonymized requests and responses, the WSDL version, endpoint, and timestamp. Do not publish certificates, passwords, or complete personal data in a report or project XML.
Limitations and common mistakes
SoapUI does not remove the need to check consumer compatibility or observe actual side effects. A successful call can save an incorrect amount or create a document twice. Common mistakes include retaining an outdated WSDL, passing a previous ID, permanently disabling certificate verification, and considering a string check a sufficient assertion. A good project explains the contract, controls data, and pinpoints failure causes. That is what makes it maintainable for enterprise integrations.