A Tier-1 US bank embarked on a multi-year programme to replace its mainframe core banking system with a cloud-based platform. The new architecture spans 50–60 microservices (mostly Java Spring Boot), each owned by a separate team. Functional testing was only happening in integrated environments — meaning issues surfaced too late, cost too much to fix, and slowed production deployments. Kafka was a critical communication layer but was barely tested. There was no schema registry, no consistent reporting, and no shared definition of what a “component test” even meant across teams.

GFT was engaged from the beginning of the programme. They started by defining and documenting a test strategy with an aligned stakeholder — a step Alberto calls “the single most important thing in a complex environment.” They then chose Karate for component testing and extended it using Java interoperability to cover databases, JMS, AWS services (S3, SQS), Redis, and Kafka:

• Embedded everything locally — Kafka, databases, Redis, and AWS services all brought up as embedded instances, so developers could test their service in total isolation without any external dependencies
• Karate mocks for cross-service dependencies — external services mocked using Karate so each team tests only what they own, with full control over the mock’s behaviour from the test itself
• Same tests reused for performance — Karate’s built-in Gatling integration let them reuse component tests as performance benchmarks without duplicating scripts
• Custom functional reporting layer — built on top of Karate’s execution reports to give stakeholders a view of test status aligned to business scenarios, not technical scenarios

Cytel builds software for the global biopharmaceutical industry — products used to design clinical trials and analyse the data they generate. The QA team were domain experts with deep statistical and clinical knowledge, but lacked strong automation skills. Their existing API tests lived inside 60–70 Postman collections, where each request carried 5,000–6,000 lines of JavaScript that manual testers had to maintain by hand for every release. The regression cycle was running four weeks, forcing quarterly releases when the business wanted monthly.

Cytel partnered with Crosslake Technologies in May 2024 to identify bottlenecks and define a path to faster iteration. They evaluated tools against 50 criteria, and chose Karate around August–September 2024 because it was the only low-code option that handled the heavy statistical calculations Cytel’s tests required, while still feeling natural to a team whose existing skills were in JavaScript and JSON.

• Hands-on training led by Peter Thomas — the creator of Karate — got the team productive immediately
• Manual rewrite of every test instead of auto-migration — chosen deliberately as a learning exercise; turned out to be the single best onboarding decision they made
• JavaScript inline inside JSON payloads handled complex inter-dependent inputs and conditional logic that other frameworks couldn’t express cleanly
• Quarterly self-assessment surveys tracked confidence growth — from initial scepticism to junior testers contributing independently within months

Launching a complex multi-tenant microservices platform meant the engineering team needed test coverage in place from day one — and they needed it without slowing developers down. The questions weren’t just about tooling; they were about who owns testing, how to keep contracts stable across dozens of services, and how to make automation fast enough that it actually shifts left rather than becoming an afterthought.

On the recommendation of an architect, the team evaluated Karate against multiple criteria — component tests, productivity, maintainability, and coverage. They adopted it across the full microservices stack and built four layers of testing on top of it:

• Component tests — rich, acceptance-driven tests verified from a business-logic perspective, using Karate mocks to stub out service dependencies
• Contract tests — JSON schema validation in one or two lines of code instead of the dozens that other tools required, ensuring no service breaks the contract with another
• Integration tests — data-driven from CSV and JSON files, with tag-based runs across development, smoke, and pre-production environments
• Quality gates in CI — component tests wired into build pipelines with automatic failure when JaCoCo code coverage drops below threshold

Dell Technologies’ engineering organisations — spanning the Client Product Group and Modern Compute Solutions Group — were architecting a growing portfolio of cloud-based microservices. Test automation was fragmented across teams, existing code-heavy API testing frameworks demanded deep programming fluency, and a large population of experienced manual testers had their domain knowledge locked behind an object-oriented programming barrier they’d never been hired to cross. Dell needed a way to scale automation across multiple independent projects, maintain quality without centralised mandates, and bring skilled manual testers into the automation fold rather than leaving them behind.

Dell ran a formal POC of Karate in May 2019. By August 2019 they had expanded adoption, and over the next four years Karate spread to a dozen projects across two business units:

• Manual testers became automation engineers — Karate’s DSL meant domain-expert QA engineers could contribute tests from day one without learning OOP
• Predominantly API testing across microservices, with a few projects also using Karate for UI automation
• Full-stack testing for cloud-native services — Prashant’s team architected Karate-based suites for end-to-end testing of cloud microservices
• Fed requirements back into the open-source framework — Dell engineers contributed feedback that shaped Karate features, including the IntelliJ plugin
• Same suite runs local and cloud — developers run against embedded services on their laptops, then the identical suite runs against cloud environments in CI

FIS is a Fortune 500 technology provider powering merchants, banks, and capital-markets firms globally. Healthy economies depend on healthy financial systems — and that makes test automation existential, not optional. But most automation frameworks assume you’re a developer. They demand object-oriented programming, framework scaffolding, and class hierarchies — barriers that lock experienced QA leaders out of writing tests themselves. Anthony, with two decades of QA experience, had spent much of his career managing contractors and third-party vendors on large implementations rather than writing automation. The result: the people with the deepest understanding of what to test couldn’t always write the tests.

Anthony spearheaded the adoption of Karate DSL across his organisation. What started as an API testing solution for his immediate team became the standard — rolled out across the wider FIS organisation — covering much more than APIs over time:

• Learned automation from scratch as a non-programmer — Karate’s plain-English syntax gave a seasoned QA leader the entry point that twenty years of OOP-heavy frameworks never did
• Scaled from one team to the whole organisation — the tool that worked for Anthony’s six-developer team became the standard for the wider FIS group
• Bridged the QA–developer divide — Karate used by both sides closed the “Tom and Jerry” gap Anthony had seen throughout his career
• Dual role without the productivity hit — juggling Scrum Master and Principal Quality Engineer responsibilities while still personally owning automation, made possible by a tool that didn’t demand programming as a prerequisite
• Fell in love with programming as a non-programmer — the story Anthony tells is ultimately about curiosity and capability meeting the right tool at the right time

How much of your testing should be API vs. UI — and why does it matter? As software architectures shift toward microservices and APIs become the durable structural layer of modern systems, most testing programmes are still disproportionately weighted toward UI automation. That creates flaky suites, slow feedback loops, and testing that breaks every time a designer touches a stylesheet. This panel tackles the balance directly: where APIs earn their investment, where UI testing still matters, and how to architect a testing programme that reflects the reality of how modern software is built.

A 45-minute conversation across five themes, moderated by Joe Colantonio:

• The increasing relevance of APIs as the architectural backbone of modern software — not just a testing surface but a product surface
• Why essential test automation is a competitive advantage — enabling the faster, more frequent releases that modern business tempo demands
• APIs as durable architectural components that simulate workflows and model real business transactions in a way UI tests cannot
• Proven solutions that simplify API testing — including how Karate makes API testing accessible to teams without deep automation expertise
• How API tests deliver broader coverage — functional and architectural — reducing the reliance on brittle UI test automation