Artificial intelligence is rapidly changing the economics of software testing. Development teams can now generate code, test cases and automation scripts in minutes, removing much of the manual work that previously slowed releases.
But the result may be a false sense of security, as a large suite of passing tests does not necessarily mean the right risks have been covered, particularly when teams do not fully understand what AI-generated tests are validating or who is responsible when they miss a critical defect.
For banks and financial institutions, this gap between testing activity and confidence presents a particular challenge.
AI may help firms respond to relentless release cycles and limited testing capacity, but regulated organisations must still demonstrate that customer journeys, business rules and critical controls work as intended. Test volume alone cannot provide that assurance, according to industry insiders.
Angie Jones, vice-president of developer experience at the Agentic AI Foundation, argued this week that software development is already moving at an unprecedented rate, with engineers producing dozens of pull requests and continuously pushing new features towards customers.
As development accelerates, teams increasingly feel that they no longer have time for a conventional testing cycle.
Generating tests alongside the code appears to offer an answer, but Jones warned that it can also obscure the difference between automated activity and meaningful assurance.
“AI can generate a lot of testing activity very quickly,” she said during an online discussion this week. “But also what I’m finding is that generation by itself doesn’t necessarily guarantee meaningful coverage.”
The problem, Jones stressed, is that large language models are typically working towards a defined objective rather than applying the broader judgement of an experienced tester.
“LLMs are very goal driven and their goal is to get to a green test,” she explained. “So sometimes they’ll satisfy that goal in ways that might technically pass, but you don’t necessarily feel an increase in confidence.”
That can leave organisations with a growing collection of successful test results without a clear indication that the application itself is stable.
In a banking environment, a technically passing test may offer little reassurance if it overlooks an incorrect payment calculation, a faulty customer authentication process or another material business risk.
“I think what we’re finding is that generating tests is not the same as generating trust,” Jones continued. “So the questions I think now become: do we have the right tests and can we trust what the tests are telling us?”
Testing cycles under pressure
AI can help close the gap between development and testing capacity, particularly for smaller teams. Jones said engineers can create a first pass of tests while a new feature remains fresh in their minds instead of waiting for a separate QA cycle.
The efficiency gain does not remove the need for a coherent quality strategy, however.
“Who owns these generated tests?” Jones asked. “Who’s responsible for maintaining them, for determining if they’re still useful six months from now? Who’s accountable when the AI creates a test that technically passes, but maybe it misses a real bug?”
“AI can absolutely help create tests faster, but it doesn’t necessarily magically create this quality strategy. Somebody still needs to own the thinking of that.”
“Generating tests is not the same as generating trust, so can we trust what the tests are telling us?”
– Angie Jones
Anand Sundaram, CEO of Applitools, who also took part in the discussion, said AI adoption in testing remains at an early stage, although organisations know they must respond to the increased pace of AI-assisted development.
Current uses include generating tests from specifications, producing test data, writing automation code and executing test suites.
However, fewer teams are applying AI to test selection or determining which parts of a suite should be run following a particular code change. That requires organisations to understand the potential blast radius of a change rather than simply executing a growing volume of automatically generated tests.
“AI is just compressing the testing life cycles and the feedback loop that used to be there earlier, that’s gone,” Sundaram stated.
“What to test is another enigma, and that requires that you know the domain and you understand the risk tolerance of the organisation for what is acceptable to be failure in production.”
That risk tolerance will be substantially different for a regulated bank running a critical payments platform than for a company able to correct relatively minor defects after release. Sundaram argued organisations must also address responsibility when automatically generated tests fail to identify a serious problem.
“Ultimately, what the other part they’re missing is: who’s accountable?” he said. “Who are responsible for the AI-generated tests that misses something critical?”
More tests, more maintenance
Maintenance could become another significant problem. As applications change, AI can create more test code, potentially expanding rather than resolving the workload facing quality engineers.
“Maintenance overload is a new problem and a phenomenon that I’m seeing among testing groups,” Sundaram said.
Brittle web tests and unreliable locators have also not disappeared simply because automation code can now be generated by AI. Meanwhile, the probabilistic character of an LLM may make it harder for teams to reproduce failures and receive the same result consistently.
“The elephant in the room is that LLMs are probabilistic,” Sundaram explained. “So it’s a statistical guess as opposed to having a deterministic model that will reliably do the same thing over and over again.”
Costs may become more visible as organisations expand their use of AI across end-to-end testing. Larger context windows can make LLMs slower and more expensive, while security, data privacy and residency create additional concerns, particularly in regulated sectors.
“Nobody’s thinking about it now and everybody’s in this rush to just get going on the AI train,” Sundaram continued.
“Security and data privacy and residency issues are also part of the challenge that some folks care about in some of the verticals that I’m dealing with.”
The eventual test for financial institutions will be whether the investment produces measurable improvements in delivery, resilience and software quality.
“When CEOs and CFOs and folks who are signing the cheque see the bills and they want to relate the outcomes to it, that’s the true test of AI really transforming it in a way that’s meaningful,” Sundaram added.
He warned that development and testing teams may otherwise accumulate a new category of technical debt. Quality engineers can find themselves reviewing unfamiliar AI-generated tests while simultaneously acting as the final control against both defective generated code and inadequate generated test cases.
“While the quantity is growing, the quality is not necessarily growing commensurately,” Sundaram said. “QE teams are now finding that they are like the guardrail and the backstop for bad stuff going out, for AI-generated code and AI-generated test cases.”
Jones described this as a risk of confusing visible activity with genuine assurance.
“You have to stop and ask yourself if those tests are actually helping the team understand risk any better,” she said. “Especially if teams can’t quickly determine which failures matter, which of these results are trustworthy, then the system is creating noise instead of confidence.”
From test author to quality strategist
The shift could ultimately strengthen the position of experienced quality professionals. Rather than concentrating primarily on authoring automation scripts, testers may increasingly define risk, assess test relevance and determine what evidence is sufficient to support a release decision.
“We move from test author to more of a quality strategist,” Jones said. “If AI can generate the checks, then the real value is in understanding whether those checks are actually meaningful or not.”
“QA becomes more about understanding risk, about always keeping the customer first, thinking about what matters to them, what behaviours hurt the business if something broke, what level of confidence we need before we release. All of this judgement work, I think, is what becomes the real value of QA.”
“AI is just compressing the testing life cycles, and the feedback loop that used to be there earlier, is gone.”
– Anand Sundaram
Sundaram similarly identified domain knowledge as a central requirement. Testers must understand the intended behaviour of an application, the needs of its users and the consequences when important controls fail.
“The roles as it evolves will be more about describing really the behaviour of the app, what needs to be tested, what is really the outcome that ensures correctness, and not about just blindly telling the LLM, ‘Go test everything,’” he stressed.
Although some organisations have reportedly reduced QA headcount after adopting AI, Sundaram said he had not yet seen convincing evidence that those reductions consistently produced greater speed and efficiency while preserving quality and confidence.
“Accountability and figuring out what’s the right testing to be done is probably where our worlds are going to evolve as QA and QE teams in all of these organisations,” he said.
Reliable validation
Teams making progress are retaining humans in the loop, curating generated tests and running them repeatedly before treating the results as reliable. Sundaram said flaky tests should either be repaired or removed, while test portfolios can be divided into different tiers.
A core group of carefully reviewed and highly trusted tests can validate the most important functions. Broader, less authoritative tests may then provide additional coverage without being treated as equivalent evidence.
“Accountability and ownership and quality over quantity,” Sundaram said. “These are all the things that people are doing right in order for them to get it to production and have a level of trust and confidence.”
Jones said agents are also changing what constitutes a reliable testing signal. Traditional test automation has often focused on implementation details, such as API responses, selectors and the state of the document object model. Agents, however, are increasingly interacting with applications visually, in much the same way as customers.
“The agent trusts the visual,” she said. “It’s not relying solely on the DOM to get the state of the application. It wants to see that complete picture and I’m believing that this has given it a signal that it can trust.”
That means teams may need to determine whether an application behaved as the customer expected, rather than limiting validation to whether a selector existed or an individual technical check passed.
Jones also questioned whether organisations can continue to treat a single test suite as the definitive source of truth. Agentic systems draw on multiple forms of information, including user intent, system responses, the interface and previous context.
“I don’t think there’s like a single source of truth anymore because of the way that agents operate,” she said. “I think it becomes more about building like a trustworthy validation layer that can serve as your source of truth.”
“If the signals are incomplete or if they’re misleading, then you confidently are making the wrong decisions.”
Human oversight
Both speakers remained cautious about allowing testing agents to operate autonomously in business-critical environments. Sundaram said organisations first need to detect failures quickly, understand their impact, identify the root cause and verify the necessary remediation.
“Ultimately, I still think that there’s got to be a good amount of human oversight for a while,” he said. “For certain types of testing I suspect we will be able to get to this autonomous state easier than some of the more business-critical.”
For Jones, the fundamental non-negotiable is a dependable validation signal.
“I only think autonomy is useful if the agent can accurately determine whether the test succeeded or failed,” she said. “If the signals are noisy or they’re hard to interpret, I think the autonomy becomes dangerous very quickly.”
“Before we hand more responsibility to AI systems, we need confidence that the validation layer itself is trustworthy. Otherwise, what we’re scaling are our mistakes.”
THIS SEPTEMBER IN LONDON
REGISTER TODAY – SIMPLY CLICK HERE
Why not become a QA Financial subscriber?
It’s entirely FREE
* Receive our weekly newsletter every Wednesday * Get priority invitations to our Forum events *
READ MORE
- Goldman puts AI coding to the test
- How to test AI models that banks do not control
- OpenAI, Filigran and SunTec: the latest vendor and product news
- Sygnum: Testing AI is ‘a measurement problem’
- Banks’ ‘code for all’ push raises testing risks
QA FINANCIAL PODCASTS
CLICK HERE TO LISTEN TO OUR EXCLUSIVE CONVERSATIONS
