Testing in the Era of AI: From QA to Trust Engineering [Testμ 2026]

Is Software Testing Dead?

He began with a tagline he said nobody in the audience should find surprising. It circulates as corridor conversation, as LinkedIn posts, and as confident declarations from AI enthusiasts: with models writing the code and pipelines doing the checks, testing is a thing of the past.

Kishor recounted a conversation with an industry peer who made exactly that prediction, giving testing a couple more years at most. Rather than argue the point, he asked a different question.

With the pipeline showing a green signal, does that peer sleep peacefully at night knowing the system will not fail? He listed the specific ways it might: a sudden spike of a million users, a data leak, or a hallucinated response going out to a customer.

The peer paused, then admitted he did not have complete trust in it. That gap between a passing build and a system someone will vouch for is the space Kishor spent the rest of the keynote describing.

The Illusion of Automated Certainty

A green pipeline is a statement about the checks somebody wrote. Kishor pointed out that it says nothing about the conditions the system will actually meet once real users, real load, and real adversaries arrive.

He then turned to the AI incidents that have made the news over the past couple of years. His reading of them was that they are not unrelated glitches, and that they cluster into a small number of ways trust breaks when AI moves out of a proof of concept or a demo and into the enterprise:

• Scale - behaviour that holds in a controlled demo degrades under a sudden, unplanned surge in users.
• Exposure - data reaches somewhere it was never meant to go, without any test asserting that it should not.
• Fabrication - the system produces an answer that is fluent, plausible, and untrue, and sends it to a customer.

Each of those, he said, carries a lesson worth taking seriously rather than filing away as bad luck. He worked through the first two in detail.

Hallucination as a Governance Risk

Kishor framed hallucination through a scenario rather than a model metric. Picture a prestigious report being delivered to a government client, where the analysis is polished and the recommendations are solid.

Nobody checks the references supporting it, and the references do not exist. He then walked through what follows on a delay:

• The citations get challenged by someone who does check.
• Corrections have to be issued and supporting references are formally requested.
• An apology becomes necessary, and the brand takes real damage.

The distinction he drew from this carried the rest of his argument. Inside a research sandbox, an invented citation is a model quality problem for the data science team to tune away.

Apply the same generative system to a business deliverable, a legal filing, or a board decision, and it stops being a model quality problem. At that point, Kishor said, it becomes a governance issue, and it belongs to whoever signed off on the deployment.

Agent Failures Are Authority Failures

For agentic AI, Kishor offered an analogy he asked the audience to sit with: an intern who has been handed the master keys. The intern is capable, willing, and entirely unaware of which doors matter.

The walkthrough was deliberately mundane. An AI agent is performing a routine task, hits a problem, searches for alternatives, finds credentials lying around, and uses them. Within seconds the production database and its backups are gone.

His emphasis was on what did not happen. The agent was not malicious and was not trying to cause damage, and it had no personal intention of any kind. It pursued the task it had been asked to do, using the authority it had been given.

That reframing moves the control point. If intent is not the variable, then testing an agent for good behaviour matters less than constraining what it is able to reach:

• Credentials - what an autonomous system can authenticate against determines its blast radius, whatever its task was.
• Tooling - powerful tools handed to an autonomous actor turn a low-probability path into a reachable one.
• Escalation - the question is not whether something unexpected happens, but what the system is permitted to do when it does.

AI Governance and the Aviation Analogy

To explain why regulators are changing the conversation, Kishor reached for aviation. When an incident involving an aircraft happens, nobody suggests moving on and forgetting about it.

It gets investigated, the investigation gets documented, the findings get reported, and the industry learns how to avoid the next one. He said that same mindset is now arriving in AI, with regulators around the world moving toward:

• Incident reporting - AI failures treated as events that must be disclosed rather than patched without a record.
• Continuous monitoring - oversight that runs while the system is live, not only at the approval gate.
• Documented evidence - a record of behaviour that somebody outside the team can inspect.
• Post-deployment oversight - accountability that continues after the launch announcement.

The consequence for quality teams is a change in the question being asked of them. Kishor put it as a move away from “did you test it?” toward “can you prove what happened after the launch?”

His conclusion was that the future of AI governance rests on evidence rather than prediction. Organisations that can monitor, document, and report AI behaviour are the ones regulators and customers will end up trusting.

From Code to Consequences

Kishor contrasted this with how testing used to sit in the delivery model. It ran as isolated testing at the end of a linear conveyor belt, working through check boxes and surfacing functional bugs, and he was blunt that the role of that model is shrinking.

The reason is that AI-enabled systems do not depend on code alone. They depend on data, models, prompts, context, and human interaction, which produces failure modes that a functional pass simply does not speak to.

He listed the mismatches directly, and they are worth reading as pairs:

Complexity, in his framing, has moved from code to consequences. The decade-old question of whether a feature works as specified is no longer enough on its own.

The question he put in its place is whether users, the business, and regulators can trust the platform at scale, under extreme stress, under attack, under ambiguity, and in real-world conditions. Framed that way, the job is creating confidence in intelligent systems rather than finding bugs in them.

Trust Engineering: Evidence Instead of Reports

Kishor traced the scope of testing across three eras. It began as a gatekeeper function, expanded through digital transformation to cover cloud, mobile, APIs, microservices, performance, accessibility, and customer experience, and AI has now expanded it again in a different form and shape.

Where traditional testing celebrated the release, trust engineering treats release readiness as one checkpoint among several. The question the practice exists to answer is what promise the organisation is making to its users, and whether it can measure that the promise is being kept.

He drew the sharpest line of the session between the two operating models. In the old one, testing produced a report; in the new one, trust engineering produces evidence, through test automation, AI evaluations, and monitoring.

Model quality on its own does not get you there. Trust, he said, has to be engineered across several surfaces at once:

• Data - what the system was trained on and what it retrieves at run time.
• Authority and identity - what the system is allowed to do and on whose behalf.
• Escalation - where a human is brought in and under what trigger.
• Monitoring - observation that continues while the system is serving traffic.
• Evidence - the durable record that makes any of the above provable to an outsider.

He was explicit that this is not a one-time event. Assurance has to be continuous because the model keeps evolving, which makes the practice something that moves rather than something that is signed off once.

Testing With AI vs Testing AI Systems

Kishor closed the technical portion by separating two terms he said get used interchangeably in the industry and mean very different things.

• Testing with AI - a productivity play. AI carries part of the testing work, and the return shows up as speed and coverage on software that behaves deterministically.
• Testing AI systems - a trust play. The system under test answers differently on identical input, so the work is establishing whether it can be relied on at all.

He noted that the first has already delivered noticeable gains for clients across verticals, and mentioned Test IO as one of the engagements where that played out. The second, he said, is the much bigger conversation, and it is evolving at a faster pace.

It is also the harder one to tool for. There is no selector to assert against and no fixed expected result, which is why building trust in the system becomes the work rather than confirming a known output.

Q & A Session

The keynote closed with a short exchange between Kishor and Maneesh Sharma, Chief Operating Officer at TestMu AI. These were the questions the session set out to answer, and how Kishor answered them.

• Is software testing dead in the age of AI?

  Kishor: Testing is not dying, it is metamorphosizing. It is transforming out of quality assurance into something much broader and far more strategic, which is trust engineering. The questions a team now has to answer are whether the system is reliable, whether it is secure, whether it is resilient, and whether it is worth trusting, and then to show the evidence that justifies each answer.

• If the pipeline is green, why is that not enough?

  Kishor: A green pipeline confirms the checks that were written for it. It does not tell you the system holds up against a sudden spike of a million users, a data leak, or a hallucinated response reaching a customer. You cannot guarantee that testing will ensure AI always acts as expected once it is scaled up and running in real-world conditions, which is why the need for certainty has never been higher.

• What separates testing with AI from testing AI systems?

  Kishor: Testing with AI is a productivity play. You bring AI into your testing and it gives you a productivity gain, and that has already produced noticeable results for clients across verticals. Testing AI systems is about building and enabling trust in the system itself, and that second conversation is much bigger and is evolving at a faster pace.

Maneesh closed by noting that AI is being embedded into every system and every process, and that quality engineering has a pivotal role in that shift. He added, half joking, that now is the time for chief quality officers, because once agents are embedded everywhere, quality has to touch every business process.

This keynote opened day one of Testμ Conf 2026, which ran across three days of sessions on agentic engineering and quality. Registrations for the next edition are already open on the Testμ Conference 2027 page.