SoapUI / ReadyAPI
The professional API testing platform for complex enterprise workflows. Best for SOAP, REST, and GraphQL testing at scale.
Overview
SoapUI, created by SmartBear in 2005, is one of the oldest dedicated API testing tools. The open-source SoapUI supports functional testing of SOAP and REST APIs with a GUI-based test builder. ReadyAPI is the commercial evolution, adding performance testing, security scanning, virtualization, and reporting.
In 2026, SoapUI/ReadyAPI remains relevant for enterprise teams with heavy SOAP legacy (financial services, government, healthcare) and complex API orchestration requirements that simpler tools cannot handle.
What it's used for
SoapUI/ReadyAPI is the right choice when:
- SOAP services are primary: Many legacy enterprise systems still use SOAP — SoapUI has the best SOAP support in the industry.
- Complex data-driven testing: Parameterise tests with Excel, databases, or custom data sources.
- API virtualization needed: Create mock services for dependent APIs that are unavailable during testing.
- Security scanning: ReadyAPI includes built-in security scans for common API vulnerabilities.
Pros & Cons
Pros
- Best-in-class SOAP support
- Powerful data-driven testing with external data sources
- API virtualization (ServiceV) for stubbing dependencies
- Security scanning built into ReadyAPI
- Comprehensive reporting and analytics
Cons
- Heavy and resource-intensive compared to Postman or REST Assured
- UI feels dated compared to modern tools
- Expensive: ReadyAPI licences start at thousands per year
- Overkill for simple REST API testing
- Smaller community than Postman
Platforms & Integrations
SoapUI runs on Windows, macOS, and Linux. ReadyAPI is Windows-primary with macOS/Linux support. Both support SOAP, REST, GraphQL, and JMS.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| SoapUI Open Source | Free | Functional testing, SOAP/REST support, basic reporting |
| ReadyAPI Test | $779/yr | Advanced testing, data-driven tests, CI integration |
| ReadyAPI Pro | $2,299/yr | Performance, security, virtualization, advanced analytics |
NZ Context
SoapUI is common in NZ government and banking sectors where SOAP services persist. NZ government agencies that have operated web services since the early 2000s still rely on SOAP-based integrations — tax filing, entitlements, and licensing portals are the most common examples. NZ banks and insurers similarly maintain SOAP layers between core banking systems and external-facing APIs, which is why SoapUI regularly appears in QA job ads at large Wellington and Auckland enterprises. Most NZ startups and modern SaaS companies have moved to Postman or code-based API testing. ReadyAPI is rarely seen outside large enterprises due to cost.
Alternatives
- Postman — Modern, lighter, and better for REST-first teams.
- REST Assured — Code-based Java alternative for teams that want tests in version control.
- Karate — BDD-style API testing with built-in performance and mocking.
When to choose SoapUI
A quick decision guide for NZ teams evaluating API / SOAP / REST testing options.
| Choose SoapUI when… | Choose something else when… | Combine with… |
|---|---|---|
| You're testing SOAP services — legacy payroll, government portals, banking integrations — where WSDL import and envelope inspection are non-negotiable | The team is REST-only and releases weekly; Postman or REST Assured will onboard faster and stay out of the way | Postman (exploratory discovery) — use SoapUI for regression suites, Postman for ad-hoc calls during development |
| Tests need external data sources — Oracle, SQL Server, Excel — to drive hundreds of scenarios across different customer segments | Budget is tight; the free tier lacks data-driven support, and ReadyAPI licences at $779–$2,299/yr are hard to justify for small teams | Jenkins or Azure DevOps — SoapUI test suites run headless via testrunner.sh, slotting neatly into existing CI pipelines |
| Dependent services are unavailable or unstable; ReadyAPI's ServiceV lets you virtualise them so testing isn't blocked by shared environments | Your team already writes Java or Kotlin; REST Assured or Karate keeps API tests in the same repo and review pipeline as the application code | WireMock or Pact — if contract testing matters more than scripted virtualisation, these integrate alongside SoapUI without replacing it |
| Security compliance is required; ReadyAPI's built-in scans cover SQL injection, XSS, and schema validation gaps without a separate tool licence | GraphQL is the primary protocol; dedicated tools like Insomnia or graphql-inspector handle introspection and fragment-level assertions more cleanly | OWASP ZAP — layer a full DAST scan on top of ReadyAPI's security checks for regulated environments (financial services, health) |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
If…
I joined a QA team at Revenue NZ (Revenue NZ) working on SOAP-based tax filing services that have been running since the early 2000s
I would…
Start with SoapUI Open Source and import the WSDLs directly — no other tool handles SOAP envelope inspection as well. I'd build a data-driven regression suite against test accounts, then push it into Azure DevOps via testrunner.sh so it runs on every release branch. I would not bother pitching ReadyAPI unless the team needed virtualisation; the open-source tier covers 90% of functional testing needs at zero cost. Groovy scripts for the edge cases only — keep them short and commented because the next tester may not be a developer.
If…
I was the lead QA at TechServNZ building a shared testing platform for multiple enterprise clients, some with SOAP, some with REST, some with mixed legacy stacks
I would…
Justify a ReadyAPI Pro licence for the ServiceV virtualisation alone — when five client environments share an integration layer and one is always broken, virtualising dependencies saves more hours than the licence costs. I'd standardise on ReadyAPI for SOAP-heavy clients and Postman Collections (run via Newman in CI) for REST-first clients, rather than forcing one tool across the board. Shared test data would live in a SQL Server fixture database, not spreadsheets — SoapUI's JDBC data source handles this cleanly and avoids the "wrong version of the Excel" problem.
If…
I was a QA engineer at Harbour Bank evaluating whether to migrate from a ten-year-old SoapUI suite to a modern code-based solution
I would…
Not migrate everything. I'd audit the existing suite first: tests that are actively maintained and catch real defects stay in SoapUI, because rewriting working tests is waste. Tests that are brittle, unused, or covering REST-only services get rewritten in REST Assured alongside the developer unit tests. The migration target is a leaner SoapUI suite (SOAP + complex orchestration only) running next to REST Assured in the same pipeline — not a full replacement. Banks that have tried big-bang tool migrations usually end up with six months of broken CI and zero new test coverage.
The bottom line: SoapUI earns its place when SOAP is real — not as a nostalgia pick. If your project has no WSDL files, close the installer and reach for Postman instead.
Interview questions
Questions you are likely to get if you list SoapUI on your CV — with what interviewers are really testing for.
Why would you choose SoapUI over Postman for API testing, and when would that decision flip?
What they’re really testing: Whether you understand tool fitness-for-purpose or just use whatever you learned first.
Strong answer covers: SoapUI’s superior SOAP/WSDL support and data-driven test suites as key differentiators; Postman winning on REST-first, lightweight, collaboration workflows; the decision point being whether WSDL files and complex orchestration are actually on the project. In NZ government or banking (e.g. Revenue NZ, Pacific Bank) SoapUI is often mandated by existing tooling.
When would you use ReadyAPI’s ServiceV virtualisation instead of WireMock or a simple stub server?
What they’re really testing: Whether you grasp service virtualisation as a discipline and can justify a premium licence cost.
Strong answer covers: ServiceV shines when the dependency is SOAP (WireMock is clunky with complex envelopes); when the virtualised service must replay realistic latency or stateful sequences; when the team already owns a ReadyAPI licence so there is no extra cost. WireMock or Pact makes more sense for REST contract testing where the stub lives alongside developer unit tests in the same repo.
You’ve joined Revenue NZ’s QA team and inherited a 500-test SoapUI suite built over eight years. Where do you start?
What they’re really testing: Maturity around legacy test assets — most candidates want to rewrite everything; experienced testers audit first.
Strong answer covers: Running the suite to see what passes, fails, and is skipped; reviewing last-failure history to identify active vs. orphaned tests; auditing Groovy scripts for hardcoded environment values or personal test accounts; and only refactoring the tests that are actively maintaining value — not a big-bang rewrite. Revenue NZ’s SOAP services are long-lived, so the suite is likely worth preserving.
Your SoapUI tests pass on your machine but fail in the Jenkins pipeline with a “connection refused” error on the SOAP endpoint — how do you debug it?
What they’re really testing: Systematic CI debugging rather than panicking or blaming the pipeline.
Strong answer covers: Checking whether the endpoint URL in the project file is environment-specific or hardcoded to localhost; confirming Jenkins has network access to the target environment (firewall rules, VPN, DNS resolution); verifying the SoapUI/ReadyAPI version on the build agent matches the project format; and running testrunner.sh locally with the same environment properties file the pipeline uses to reproduce before touching any test code.
How would you structure a SoapUI regression suite so it can scale from one tester to a team of five without everyone overwriting each other’s work?
What they’re really testing: Whether you’ve thought about collaboration and version control, not just test creation.
Strong answer covers: Storing the .xml project file in Git and agreeing on one project-per-service (not one monolithic project) to minimise merge conflicts; externalising environment URLs and credentials into property files checked in separately; naming test suites and cases consistently so ownership is clear; and running the suite headlessly via testrunner.sh in CI so the GUI is optional, not required, for results.