This large global retailer boasts a highly valuable brand, and CX (customer experience) is paramount in their customer-facing web and mobile app engagements. They also rely heavily on internal API programs to optimize the many and complex systems that allow them to run e-commerce, physical (brick and mortar) stores, and delivery/ logistics services on a global scale. With so many moving parts plus the need to support their innovative brand, the retailer realized that they needed to embrace agile development and strive for incremental development.
As the retailer faced the daunting challenge of moving from monolith to microservices, they teamed up with Capgemini with a focus on introducing more automation and accelerating innovation. Development and testing teams would not be surprised to soon see a much greater emphasis on APIs in the implementation of continuous integration (CI) processes. With CI in place, developers would hopefully gain much more production-ready code to help improve and/or accelerate releases.
However, it soon became apparent that the shortened release cycles were raising risk to unacceptable levels. One small change by any of the siloed, distributed teams working on a web platform or mobile app would sometimes cause vital integrations to fail.
One early response to the problem was for senior management to look closer at the API testing automation powered by a centralized API management platform, and scheduled by a Jenkins CI/CD pipeline. The senior leaders were unable to learn much from the testing tools: UI testing simply cannot detect or diagnose backend API errors — and the APIM’s onboard API testing and monitoring tool had three major flaws that may have been partially responsible for allowing bad code to get into the repository:
Unusable Feedback: If a bug was detected, no detailed dashboards or reporting was available to quickly diagnose and fix the bug.
Low End-to-End Observability: Many bugs are due to server-side issues and human error - things that get lost in translation among distributed teams; API testing must be powerful enough to detect the full range of API issues.
Siloed Expertise: Team members that use the APIM are specialists, who are not testing experts. Also, testing experts typically do not know how to use the testing tool in an APIM.
Lead Solutions PaaS Architect at Capgemini, Sander Rensen, has managed the successful rollout of API-first development at many enterprises. Rensen joined the leadership team responsible for finding a more powerful API testing and monitoring solution for the global retailer. After looking at several top providers, Rensen was pleased by the performance of API Fortress, now known as Sauce Labs API Testing and Monitoring.
Today, the retailer reports that they have significantly increased regression testing without increasing headcount. Due to the ease of building and testing in parallel, testing times have been reduced by over 40% with far fewer bottlenecks. A great reduction in false-negatives combined with highly accelerated bug diagnosis and remediation has enabled the retailer to achieve consistent quality-at-speed, giving developers the confidence to increase velocity and complete more points during sprints.