Systems | Development | Analytics | API | Testing

Oracle’s Fusion Agentic Applications represent a new class of enterprise software. They contain coordinated teams of outcome-driven, proactive AI agents that are engineered to execute business processes across finance, HR, supply chain, and customer experience. For folks who work in those departments, these agents may streamline some of their daily work and help uplevel employees. For testers, they bring a measure of ambiguity. In general, you know how humans use these applications.

By now everyone is aware of the limitations inherent in generative AI and the AI agents that use it to complete their tasks, and the challenges involved in getting them enterprise quality. If you are planning to incorporate AI agents into your enterprise IT architecture, how are you planning to validate their quality and accuracy?

For the first time ever, artificial intelligence has topped NASCIO’s annual ranking of state CIO priorities, ending cybersecurity’s 12-year reign at number one. It’s easy to see why: public agencies – like their private sector counterparts – see real potential in AI to modernize operations, accelerate service delivery, and help lean teams do more with fewer resources.

Every AI headline this year is about speed: code shipping faster, test scripts generating in seconds, releases compressing from weeks to days. What gets less attention is what happens to quality when everything around it accelerates and the way you manage testing doesn’t.

Software runs mission delivery in the public sector. As agencies modernize and systems grow more connected, the cost of a failed release climbs. The result can be service disruptions, compliance gaps, and loss of public trust. Automated testing is central to managing that risk, but it raises a practical question: which approach is right? Two options come up often: robotic process automation (RPA) and model-based testing (MBT). Both support automation, but they were built for very different purposes.

Picture a large-scale grocery and retail chain launching its first online storefront. The setup is complicated: a single online order must travel through an SAP eCommerce platform, multiple payment and loyalty systems, before disappearing into back-end SAP supply chain and ERP apps. The complexity of merging the online and offline business is like a “digital tsunami.” For many SAP enterprises, this sounds familiar.

Quick summary: Performance teams can generate tests in minutes, but the analysis still takes hours. Agentic Performance Testing in NeoLoad uses domain-specialized AI agents to deliver a finished analysis from a single request, so engineers can start with the conclusions, rather than the raw data. Performance testing answers a critical question in the quality engineering lifecycle: will this hold up when real people use it, under real conditions, at real volume?

ABAP turned 43 this year — “an unusually long run,” as Sonja Liénard, head of ABAP platform at SAP, put it in a recent interview. SAP’s proprietary language has been reinvented numerous times, from procedural code to today’s ABAP Cloud, to keep up with market demands. The same cannot be said for ABAP testing. Most SAP teams are deciding what to test the way they did twenty years ago: run the full regression suite and hope it holds.

At Datadog DASH in the spring, the Tricentis NeoLoad team met folks in all types of roles – developers, test engineers, CoE leads, and SREs – and one recurring theme we found was that SREs often didn’t know much about how performance validation happens at their companies. That’s a fair division of labor. Seemingly, the performance team’s work would be related but not mission-critical to the infrastructure team’s. But that’s not entirely true.

Over the past twelve months, something has shifted in how software teams think about quality. Claude Code, Cursor, and Playwright agents have made it genuinely easy to generate functional tests without deep automation expertise. The impact is showing up across two very different kinds of teams: Both paths lead to the same place: tests accumulate without governance, you get coverage without traceability, and there’s automation debt no one owns. But coverage numbers and quality are not the same thing.