How to Test SOAP API: WSDL, XML, Assertions, and Tools

How to test SOAP API services is still an important QA skill, especially in banking, insurance, healthcare, telecom, travel, enterprise integrations, and legacy modernization projects. REST and GraphQL get more attention, but many critical systems still depend on SOAP contracts, WSDL files, XML schemas, strict operations, and SOAP faults.

This guide explains SOAP API testing from the ground up. You will learn how to read a WSDL, build XML requests, validate responses, test faults, use tools like SoapUI and Postman, automate checks, handle authentication, and avoid common mistakes that make SOAP testing slow and unreliable.

How to Test SOAP API Services: The Short Workflow

To test a SOAP API, start by reviewing the WSDL contract, then generate or write valid SOAP XML requests, send them to the correct endpoint, validate HTTP status, SOAP envelope structure, response XML, schema rules, business fields, and SOAP faults. Add negative, security, boundary, and integration tests before automating stable scenarios.

SOAP testing is more contract-heavy than many REST tests. A small namespace mistake can make a request invalid. A missing required element can produce a SOAP Fault. A field may be valid XML but invalid business data. A service may return HTTP 200 while the body contains a fault. Testers need to inspect both transport behavior and XML content.

If you are new to API testing generally, start with API testing tutorial, then return here for SOAP-specific details.

What Is a SOAP API?

SOAP stands for Simple Object Access Protocol. It is a messaging protocol that commonly uses XML over HTTP. SOAP APIs expose operations, such as CreateCustomer, GetPolicy, SubmitClaim, or CheckInventory. The contract is usually described by a WSDL file.

A SOAP message usually has:

• Envelope.
• Optional Header.
• Body.
• Operation-specific request or response.
• Optional Fault for errors.

Example SOAP request:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:cus="http://example.com/customer">
  <soapenv:Header/>
  <soapenv:Body>
    <cus:GetCustomerRequest>
      <cus:CustomerId>12345</cus:CustomerId>
    </cus:GetCustomerRequest>
  </soapenv:Body>
</soapenv:Envelope>

The XML must match the expected namespaces, elements, and data types. SOAP services are often strict. That strictness is useful for contracts, but it makes test data and request construction important.

SOAP vs REST Testing

SOAP and REST testing share API fundamentals: inputs, outputs, auth, error handling, contracts, data, and integration. The mechanics differ.

Area	SOAP API Testing	REST API Testing
Contract	WSDL and XSD	OpenAPI, docs, JSON schema
Payload	XML envelope	Usually JSON
Operation style	Named operations	Resource and method style
Errors	SOAP Fault plus HTTP	HTTP status plus error body
Validation	XML schema, namespaces	JSON schema, fields
Tools	SoapUI, ReadyAPI, Postman	Postman, Rest Assured, Playwright API
Security	WS-Security, certificates, headers	OAuth, JWT, API keys, mTLS

Do not test SOAP as if it were JSON REST with angle brackets. SOAP has its own contract model. WSDL, XSD, namespaces, SOAPAction, headers, and faults matter.

Read the WSDL First

The WSDL is the service contract. It describes operations, messages, bindings, endpoints, and types. QA should review it before writing test cases.

Look for:

• Service endpoint.
• Available operations.
• Request and response message names.
• Required and optional elements.
• Data types.
• Min and max occurrences.
• Enumerations.
• Length restrictions.
• Namespaces.
• SOAPAction values.
• Fault definitions.

The WSDL tells you what the service promises. If the WSDL says CustomerId is required, you need a positive test with it and a negative test without it. If an element has an enum of ACTIVE, INACTIVE, and SUSPENDED, test valid and invalid values. If max length is 20, test boundary values.

Use the WSDL to derive test cases rather than guessing from examples. Examples often show only the happy path.

Tools for SOAP API Testing

SoapUI is a strong SOAP testing tool because it can import WSDL files and generate request templates. It also supports assertions, environments, properties, test suites, and data-driven testing.

Postman can send SOAP requests because SOAP is HTTP plus XML, but it does not provide the same SOAP-native WSDL workflow. It can still be useful when your team already uses Postman and only needs a few SOAP checks.

Other options include ReadyAPI, Java HTTP clients, Python requests, Rest Assured XML support, and custom frameworks.

Tool	Best Fit	Notes
SoapUI	Manual and automated SOAP testing	Strong WSDL import and SOAP assertions
ReadyAPI	Enterprise SOAP and service virtualization	Commercial features for larger teams
Postman	Simple SOAP requests and sharing	Good for teams already using collections
Java framework	Code-based regression	Useful when SOAP checks live with Java automation
Python requests	Lightweight scripted checks	Flexible, but you build structure yourself

Tool choice depends on team skill and maintenance. If testers are exploring WSDL operations, SoapUI is efficient. If the SOAP service is one part of a broader code-based suite, a framework may be better.

Create Positive SOAP Test Cases

Start with successful operation tests. For each operation, identify the valid minimum request and the valid full request.

Example positive cases for GetCustomer:

• Existing customer ID returns customer details.
• Customer with multiple addresses returns all expected address nodes.
• Customer with inactive status returns inactive status correctly.
• Request with optional locale returns localized labels.
• Request with valid authentication header returns success.

Assertions should include:

• HTTP status.
• No SOAP Fault.
• Correct response operation.
• Required XML elements exist.
• Key business fields have expected values.
• XML schema is valid.
• Response time is acceptable for functional testing.

Example SoapUI-style assertion goals:

HTTP Status: 200
XPath: count(//CustomerId) = 1
XPath: //CustomerId/text() = "12345"
XPath: //Status/text() = "ACTIVE"
Not Contains: <soap:Fault>
Schema Compliance: valid

Do not rely only on "response is not empty." SOAP services can return a valid-looking envelope with wrong data.

Negative Testing for SOAP APIs

Negative tests are essential because SOAP services often enforce strict contracts.

Test:

• Missing required element.
• Empty required element.
• Invalid data type.
• Invalid enum value.
• Value too long.
• Unknown ID.
• Duplicate transaction.
• Invalid namespace.
• Missing SOAPAction.
• Invalid authentication header.
• Expired certificate or token.
• Unauthorized role.

Expected behavior may be a SOAP Fault, a business error response, or an HTTP status. The contract should define this. If it does not, raise a question.

Example fault:

<soap:Fault>
  <faultcode>soap:Client</faultcode>
  <faultstring>Invalid CustomerId</faultstring>
  <detail>
    <errorCode>CUSTOMER_NOT_FOUND</errorCode>
  </detail>
</soap:Fault>

Validate stable error codes more than fragile message text. Message text can change for wording or localization. Error codes and fault structure are better regression signals.

XML Schema and XPath Assertions

SOAP response validation often uses XSD schema checks and XPath assertions.

Schema validation answers: does the XML match the expected structure and types?

XPath answers: does a specific value or node exist?

Use both. Schema validation cannot prove business correctness. XPath cannot easily validate the full structure.

Example XPath checks:

count(//cus:Customer) = 1
//cus:Customer/cus:Status/text() = 'ACTIVE'
//cus:Customer/cus:Addresses/cus:Address[1]/cus:Country/text() = 'IN'
not(//soap:Fault)

Namespace handling is a common source of mistakes. XPath expressions must account for namespaces. A query that works without namespaces in one tool may fail in another. Define namespace prefixes clearly in the tool or framework.

For data-heavy responses, avoid asserting every node in every test. Use schema validation for shape and focused XPath assertions for business behavior.

Testing SOAP Headers and Security

SOAP APIs often use headers for security, routing, correlation IDs, locale, or transaction metadata. WS-Security may include username tokens, timestamps, signatures, encryption, or certificates.

Test:

• Valid security header.
• Missing security header.
• Invalid username or password.
• Expired timestamp.
• Invalid signature.
• Wrong certificate.
• Missing correlation ID if required.
• Duplicate transaction ID.
• Unauthorized role.

Security failures should not leak sensitive details. A response should not reveal whether a username exists or expose internal stack traces.

Also test replay behavior when timestamps or nonce values are used. Some SOAP services should reject reused messages. This matters in financial and enterprise integrations.

Data-Driven SOAP Testing

SOAP services often have complex business rules. Data-driven testing helps cover combinations without copying full XML requests.

For example, a policy quote service might depend on:

• Product type.
• Customer age.
• Country.
• Coverage amount.
• Effective date.
• Discount code.
• Existing customer status.

Instead of writing separate XML files by hand for every case, use a template and replace values from a data table.

Case	Age	Coverage	Expected Result
Minimum valid age	18	100000	Quote returned
Below minimum age	17	100000	Validation fault
High coverage	35	1000000	Manual review required
Invalid coverage	35	0	Validation fault

Keep data tables readable. If test data becomes huge, split it by rule area. A giant spreadsheet with fifty columns is hard to review.

Testing SOAP Faults in Detail

SOAP Fault testing deserves its own attention because many SOAP integrations depend on predictable error handling. A client may route faults to support queues, retry jobs, fraud review, or customer-facing messages. If the fault contract changes, downstream systems can break even when the HTTP status looks acceptable.

Validate these fault details:

• Fault code.
• Fault string or stable message field.
• Detail element.
• Business error code.
• Correlation or transaction ID.
• Whether the fault is retryable.
• Whether sensitive information is hidden.

For example, a missing required field should usually produce a client-side fault or validation error. A provider database outage may produce a server-side fault. A duplicate submission may produce a business fault. These are different outcomes and clients often handle them differently.

Create a fault matrix:

Fault Scenario	Input Change	Expected Fault
Missing required ID	Remove CustomerId	Validation error
Unknown ID	Use valid format but nonexistent ID	Customer not found
Invalid role	Use token without permission	Authorization fault
Duplicate transaction	Reuse transaction ID	Duplicate request fault
Expired timestamp	Send old WS-Security timestamp	Security fault

Do not accept stack traces, database messages, or internal class names in fault details. SOAP services are often connected to enterprise systems, and error leakage can become a security and support problem.

Backward Compatibility for SOAP Consumers

SOAP contracts often live for years because external clients integrate against them. A small WSDL change can have a large impact. QA should treat backward compatibility as a first-class testing concern.

Check whether changes are additive or breaking. Adding an optional element is usually safer than renaming an element. Changing a namespace, removing an operation, changing a required field, or modifying a data type can break generated client code.

Regression tests should keep sample requests from important consumers where possible. If a bank partner, insurance broker, or internal legacy client sends a known request shape, preserve it as a compatibility test. Then run it after WSDL or schema changes.

Also validate versioning rules. Some organizations expose a new endpoint or namespace for breaking changes. Others attempt backward-compatible evolution inside the same service. QA needs to know the policy before approving changes.

Automating SOAP API Tests

Automate stable SOAP checks after you understand the contract and data. Automation can run through SoapUI projects, Maven plugins, Java frameworks, Python scripts, or CI collection runners.

Good automation structure includes:

• Environment-specific endpoints.
• Reusable XML templates.
• Secure credential management.
• XPath helpers.
• Schema validation.
• Test data files.
• Request and response logging.
• Clear reports.
• Cleanup where operations create data.

Example Java-style SOAP request using a raw HTTP client:

String xml = Files.readString(Path.of("src/test/resources/get-customer.xml"))
    .replace("${customerId}", "12345");

HttpRequest request = HttpRequest.newBuilder()
    .uri(URI.create(baseUrl + "/CustomerService"))
    .header("Content-Type", "text/xml; charset=utf-8")
    .header("SOAPAction", "GetCustomer")
    .POST(HttpRequest.BodyPublishers.ofString(xml))
    .build();

HttpResponse<String> response = client.send(request, BodyHandlers.ofString());

assertEquals(200, response.statusCode());
assertFalse(response.body().contains("<soap:Fault>"));

In real frameworks, parse XML rather than checking strings for all assertions. String checks are acceptable for simple smoke tests but weak for complex validation.

For general framework design, see API automation framework.

Common Mistakes When Testing SOAP APIs

The first mistake is ignoring the WSDL. Test cases should come from the contract. If testers use only sample requests, they miss required fields, optional fields, data types, and fault definitions.

The second mistake is treating HTTP 200 as success. SOAP faults can appear inside HTTP 200 responses depending on implementation. Always inspect the body.

The third mistake is breaking namespaces accidentally. Namespace prefixes and URIs matter. A request can fail even when the visible XML looks close to correct.

The fourth mistake is validating only happy paths. SOAP services often protect critical enterprise workflows, so negative tests for invalid data and unauthorized access are essential.

The fifth mistake is copying huge XML payloads across tests. Use templates, builders, or data-driven inputs. Copy-paste makes contract changes painful.

The sixth mistake is asserting brittle full XML strings. XML formatting, prefix names, and element order can vary. Use schema and XPath where appropriate.

The seventh mistake is skipping security headers in lower environments. If security is disabled in QA, the tests may miss production-only failures.

The eighth mistake is not testing backward compatibility. SOAP services often support long-lived enterprise clients. A schema or operation change can break consumers.

SOAP API Test Case Template

Use this template for important SOAP operations:

Field	What to Capture
Operation	WSDL operation name
Endpoint	Service URL
SOAPAction	Required action value
Preconditions	Data and auth state
Request XML	Template or file path
Test Data	Values injected into XML
Expected HTTP Status	Transport result
Expected SOAP Result	Response or fault
Schema Check	XSD validation requirement
XPath Assertions	Business field checks
Security	Header, token, certificate, role
Cleanup	Any created data or state reset

SOAP testing rewards precision. The contract is explicit, so your test cases should be explicit too.

Where QABattle Fits in Your Practice

SOAP APIs can feel old-fashioned, but the testing thinking is valuable. You learn contract reading, structured input design, negative testing, error validation, and integration risk. Those skills transfer to REST, GraphQL, event APIs, and agentic systems.

Use the QABattle testing battles to practice turning contracts into test ideas. For a SOAP operation, challenge yourself to identify required fields, optional fields, invalid values, fault expectations, and security boundaries before running any tool.

Practical Release Checklist for SOAP APIs

Before a SOAP service change is approved, run a focused release checklist. Confirm that the WSDL is reachable from the expected environment and that the endpoint URL is correct. Import the WSDL into the test tool again, because cached tool projects can hide contract problems. Run at least one valid request per changed operation and one negative request per important validation rule.

Check security in the same environment that will be used for release. If lower environments disable certificates, signatures, timestamps, or username tokens, they cannot prove production readiness. At minimum, staging should exercise the same security mechanism as production with safe test credentials.

Also verify operational evidence. SOAP integrations often depend on logs, correlation IDs, audit records, and retry queues. A response can be correct while the system fails to create the audit trail needed for support. Include one test where you trace a request from client call to service log to business record.

Finally, keep at least one saved request and response pair for each critical operation. These pairs help future testers compare behavior after schema changes, tool upgrades, certificate rotation, or endpoint migration. They also make defect reports clearer because the exact XML evidence is already available.

How to test SOAP API services comes down to disciplined contract testing. Read the WSDL, build valid XML, validate schema and business behavior, test faults, secure the service, and automate the checks that protect critical integrations.