20 years of SoapUI - Share your story

Throw back to the past - 10 years ago, Ole Lensmar (SoapUI's creator) was interviewed on why and how SoapUI was created!

https://www.youtube.com/watch?v=jcOJPey7aMU

About 10 years ago, I worked on an enterprise integration project where multiple external partners had to securely connect with our internal systems through a centralized gateway built on IBM DataPower and Oracle Service Bus (OSB). One of the biggest challenges was validating complex SOAP and REST services involving certificates, security tokens, and multi-step request/response flows across systems.

SoapUI quickly became more than just a testing tool for me—it turned into a lightweight innovation platform to solve day-to-day integration challenges.

Beyond standard functional testing, I introduced a few creative approaches using SoapUI:

• Dynamic test data generation part, Instead of relying on static payloads, I used Groovy scripting within SoapUI to dynamically generate request data (timestamps, tokens, randomized IDs). This helped uncover edge cases that were otherwise missed in repetitive testing.
• Reusable test frameworks which I designed modular test suites where common authentication steps (SSL, WS-Security headers, tokens) were centralized and reused across multiple services. This significantly reduced duplication and improved consistency across SOAP and REST validations.
• Mock-driven parallel development While backend services were still under development, I created mock services in SoapUI to simulate partner systems and downstream dependencies. This allowed frontend and middleware teams to continue testing without waiting—saving critical project time.
• Gateway validation accelerator for IBM DataPower validations, I built a set of pre-configured SoapUI projects that could quickly verify security policies, routing rules, and transformations. This became a shared utility across the team, speeding up regression cycles.
• Error simulation and resilience testing which I intentionally crafted malformed requests, invalid certificates, and boundary payloads to test how the system behaved under failure scenarios. This helped us proactively fix issues in the gateway and OSB layer before production.

One memorable scenario involved intermittent request failures from an external partner. Using SoapUI, I simulated real client requests with proper SSL and WS-Security configurations, then isolated the issue by mocking dependencies and testing transformations step by step. The root cause turned out to be a namespace mismatch in Oracle Service Bus that only surfaced under specific payload conditions—something we might have missed without this level of controlled testing.

In addition to these innovations, I used SoapUI extensively for:

End-to-end functional and regression testing of SOA and REST services

Validating DataPower gateway capabilities around security, control, and integration

Ensuring API compliance across B2B and cloud integrations

Supporting basic load and performance validation before releases

That experience really changed how I approached integration testing. SoapUI wasn’t just helping validate services, it enabled smarter testing strategies, faster troubleshooting, and better collaboration across teams. Even today, I still rely on it for quick validation, mocking, and experimentation in complex service-oriented environments.

SoapUI was a precious tool when I started working with APIs. SoapUI provided visualization, making APIs much easier to understand. I used SoapUI in various API training sessions and saw its impact. We have used SoapUI on large projects involving hundreds of APIs and successfully automated tests using Groovy scripting. 

Working with SoapUI was a joy. Its simplicity and versatility made SoapUI the best choice for both beginners and experts. Many other API testing tools currently available stand on the shoulders of SoapUI. SoapUI has its place in a gallery of good software design.

I graduated in 2007 with a degree in Artificial Intelligence & Cybernetics and started my career in QA during the financial crash (great timing). An early role in accessibility testing led me into a long path across quality engineering, consulting, and advocacy.

Around that time, a few testing tools stood out including AutomatedQA’s TestComplete and Eviware’s SoapUI. SoapUI, in particular, has been a constant throughout my career whenever I’ve needed to work with SOAP APIs.

Despite being less common today, SOAP is still very much out there and often in long-lived systems where “if it ain’t broke, don’t fix it” applies.

I remember a client project when we had to integrate with a particularly unreliable SOAP service. The saving grace was a SoapUI project provided by the vendor, which gave us everything we needed — endpoints, flows, environments and allowed us to experiment and build a more resilient solution around a flaky API.

Yes, the UI hasn’t changed much over the years, but there’s something reassuring about opening a tool and knowing exactly where everything is, so you can just get on with the job. For those that want the familiarity of the existing SoapUI interface, but with an accessible modern twist, I would recommend checking out ReadyAPI ( SoapUI’s commercial counterpart, once called SoapUI Pro ) as it is the evolution of SoapUI for a modern AI-enabled API testing era.

Yousaf Nabi, Developer Advocate at SmartBear.

¡Felices 20 años, SoapUI! Mi historia con esta herramienta comenzó hace unos 11 años. En aquel entonces trabajaba como ScrumMaster y buscaba la forma de eliminar el cuello de botella en el desarrollo que era no contar con acceso a los entornos de desarrollo ni de pruebas. No imaginaba que SoapUI se convertiría en el pilar técnico que me permitiría, años después, compartir mis aprendizajes en escenarios como HandsOnTesting 2025 y Quality Sense Conf 2025.

Mi viaje comenzó con la creación de mockservices estáticos para servicios SOAP, y gradualmente evolucionó hacia la simulación de ecosistemas financieros dinámicos. Por ejemplo, para el desarrollo de una App de Tarjetas de Crédito, me apoyé en Groovy para construir respuestas dinámicas simuladas basadas en archivos preexistentes, concatenando diversos XMLs según los servicios solicitados.

Pero no quedó ahí. En un proyecto posterior, me enfrenté a que el despliegue y actualización de los mockservices —incluso utilizando contenedores Docker— seguía sin ser lo suficientemente rápido ni óptimo para el ritmo que requeríamos. Como ya había logrado dotar a los mocks de un comportamiento bastante realista, decidí resolver la fricción del despliegue con una API real sobre el mismo MockServiceRunner que nos permitió administrar y actualizar los servicios REST "al vuelo", otorgando una flexibilidad total e inmediata a los entornos de pruebas.

En mi charla en Montevideo (QSConf 2025), mostré cómo importar la interacción grabada con un proxy HTTP entre las apps móviles y su backend para generar automáticamente un entorno alterno completamente simulado. Esto permitió que los equipos de iOS and Android avanzaran en paralelo, que los analistas aislaran las funcionalidades que querían revisar y que los testers probaran casos de borde difíciles o imposibles de recrear, rompiendo por completo la dependencia del backend real.

A lo largo de estos años he creado decenas de mockservices que han servido para destrabar dependencias críticas en múltiples iniciativas de desarrollo. Lo que compartí en mis pláticas del año pasado no es solo teoría, sino un caso de uso real, contemporáneo y plenamente vigente en la arquitectura actual de microservicios; a sus 20 años, SoapUI sigue siendo mi herramienta definitiva para habilitar la agilidad y la autonomía de los equipos.

¡Gracias, SoapUI, por ser el motor de tantas soluciones y por permitirnos tomar el control de nuestros entornos de prueba!