Salesforce Testing in the Age of AI Agents: What Five Practitioners Said at Test Dreamin' 2026
Based on the panel "The Future of Testing in the Era of AI Agents," Test Dreamin' 2026, hosted by TestZeus.
The Panel
Robin Gupta (Moderator): CEO and Co-founder, TestZeus
Keir Bowden: independent consultant and Salesforce MVP Hall of Fame member
Piyusha Pilania: solution architect and Salesforce MVP
Christina Nava: Director of Salesforce Strategy at Gaggle
Carmel N. James: Salesforce consultant at SweetSpot Solutions
Abhinav Gupta: Founder of Concret.io
The question that opened the session came straight from the chat: will AI replace testers? The answer was no, and most of that first reply went on what changes instead. Over the next hour the panel covered Salesforce testing in practice: why QA keeps ending up at the tail of a project, how to test an Agentforce agent whose output varies from run to run, what to do with the Selenium or Playwright suite you already have, and where a team with a small budget should start.
This post pulls those threads together. Everything below comes from what the panelists said on the day.
Will AI replace testers? The job moves from writing scripts to curating them
One panelist's argument was that roles generally shift from execution to curation. Instead of writing and running scripts, testers will shape and guide the AI agents that write and execute tests for them. AI is good at volume. With a large enough budget it will follow every user journey, generate every combination of input data, and rerun a suite as many times as asked without getting bored.
But QA has never been about volume. It is about knowing what is important to test, where the risks sit, and what a correct result looks like. The same panelist made a narrower claim, which is best read as one person's view rather than a settled fact: AI is not very good at trying to break systems, because it wants to be positive and follow rules, while people are good at doing neither. That makes humans the better source of negative tests.
He also described a second direction that doesn't depend on automating what already exists. Digital twins, meaning virtual models of how a particular kind of person behaves and reacts, would let a team ask for a busy sales rep, a new admin or an angry customer and run the same tests as each. Persona-based testing at that scale hasn't been practical, because there were never enough people to throw at it. His suggestion was to ask what AI makes possible that never was before, instead of only asking which parts of today's lifecycle can be automated.
The panel was cautious about trust:
Handing credentials to any AI tool that works with real data was called a step too far.
Another panelist compared AI to a child not yet past two years old, and said the work is to set the right expectations.
A third said she uses AI only for things she can verify immediately, such as rewording text or cleaning up a spreadsheet.
Why does QA land at the end of Salesforce projects?
The moderator asked why QA gets left behind in Salesforce implementations. Several panelists answered, and their reasons fit together.
The strategy director gave three:
Testing is treated as a phase, not a discipline. By the time features are built and demos are ready, the timeline has shrunk and QA becomes reactive.
Salesforce is seen as low-code, so low-risk. She said that isn't true. Data models, integrations, declarative and programmatic automations and user permissions all carry risk, and the simple surface hides it.
Ownership is unclear. If everyone owns it, no one owns it.
The solution architect described the schedule mechanics. In enterprise implementations the design phase runs long and development runs long, but the release date doesn't move, so testing is the phase that gets squeezed. The founder pointed to a different cause: developers tend to test the happy path they built for, while a QA professional looks at edge conditions, concurrent user updates and governor limit boundaries.
Where the panel wanted QA to move earlier
Every fix moved QA earlier, but each in a slightly different place:
In architecture. QA should be in the room when a solution architect designs an integration pattern or data flow, asking how boundary data will be validated across systems, what mock data is needed and how failure recovery will be tested. If QA first sees the feature in the UAT sandbox, the technical debt has already built up.
In requirements. The business analyst, or whoever writes the requirements, should be the first person to own testing. They state how the feature is expected to be tested, then try it as the end user, which can catch a solution that won't solve the problem before anyone else sees it.
In sprint planning. Involving QA in planning and acceptance criteria leads developers to write better code from the start, because they know which failure cases will be tested.
In the definition of done. A ticket shouldn't be done at pull request merge. It should be done when automated regression checks pass, exploratory testing has happened and documentation is updated. Developers' unit tests should assert meaningful business logic rather than only meet the 75% code coverage deployment requirement.
The strategy director added that testing works best when it is repeatable: reuse what has already been tested, build consistency into how things are validated, and name an owner. Her summary was that quality doesn't happen by accident, and that the aim isn't to slow a project down but to avoid the cleanup afterward, which is what actually costs time.
How do you test an Agentforce agent when the output changes every time?
The moderator framed the shift this way: deterministic software, where input A always produces output B, is giving way to probabilistic systems. The independent consultant called it the biggest architectural shift in quality engineering right now. Classic automation asserts that an expected value equals an actual value. An agent might pick different tools, build queries differently or phrase the same answer several ways, so an exact string match is the wrong test.
His list of what to check instead:
Action and tool selection: did the agent invoke the correct flow, Apex action or external API?
Knowledge retrieval: did it ground its reasoning on the right knowledge articles and records?
Guardrails and safety: did it refuse unauthorized actions and out-of-scope requests?
In his description, testing moves from binary pass/fail assertions toward evaluation frameworks that run synthetic user interactions at scale and measure accuracy, semantic similarity, topic drift and hallucination rates.
The conversational side
Business users don't interact with an agent the way they fill in form fields. They use slang, fragments and ambiguous requests. QA has to ask:
What happens when a user changes their mind mid-conversation or gives contradictory information across two prompts?
Does a confused agent escalate to a person with full context, or loop until the customer gives up?
The strategy director argued that this kind of journey evaluation needs human empathy and domain knowledge that automated runners can't supply alone.
The security side
A Salesforce consultant on the panel took the security view. Salesforce security rests on profiles, permission sets, sharing rules and field-level security, so the question is whether an agent acting on behalf of a user respects those boundaries. Testers need to run prompt injection and privilege escalation checks, for example whether a standard customer can coax an agent into revealing internal case notes or another user's personal data. If permissions are loose, an agent can bypass assumptions that page layout visibility used to protect.
Should you throw out your existing automation suite?
An audience member asked whether teams should drop existing suites built in tools such as Selenium, Playwright, Provar or TestZeus now that AI test generators are everywhere. The founder's answer was direct: never throw away working, deterministic regression suites. Core transactional paths, such as processing a payment, updating an opportunity stage or creating a contact, need guaranteed pass/fail checks.
He sees AI as useful for:
generating test data
finding edge cases
scaffolding Playwright or Jest scripts
Stable execution engines should keep running the CI/CD pipeline. AI should improve how tests are authored without making pipeline runs unpredictable.
The solution architect focused on maintenance. If a suite breaks every time Salesforce ships a seasonal release or changes shadow DOM components, a team ends up spending its time fixing locators. Her advice was to put foundational effort into tools with resilient locators and clear API-level testing.
Where should a small team start?
For teams with a lean headcount and limited budget, the founder's advice was to prioritize. Decide which flows deserve full end-to-end testing and which can wait, such as internal admin screens that are neither customer-facing nor transactional. If a business flow is hit daily by 70 to 80 percent of customers, it deserves everything, and the rest can wait.
How should teams adopt AI without chaos?
The panel agreed on discipline more than on any single tactic. Each panelist offered one rule:
Pilot first. Pick one or two use cases, test them, and check whether customers wanted AI or simply wanted working software. Teams should put guardrails on their own enthusiasm before they put guardrails on AI.
Define the return up front. Projects often feel successful because everyone seemed to move faster, and on inspection the difference is small.
Assign accountability. Decide who is responsible if something goes wrong, and keep a human responsible for the correctness of what AI generates.
Be clear about what AI is. Many people treat it as another person.
Set expectations. A project judged against the wrong expectation gets devalued and fizzles out. "Garbage in, garbage out" applies to the questions asked of AI as well.
What should early-career testers learn?
Asked what newer testers should study, the panel gave three answers:
Platform fundamentals and critical evaluation. Learn data modeling, object relationships, async Apex, Flows and integration architecture, because understanding the engine is how you diagnose why an AI-generated solution fails. Anyone can ask an LLM for 50 test cases. The skill is spotting the 45 that are redundant and the five important edge cases it missed.
Business analysis and requirements work. Flawed requirements make perfectly working code a failure.
Hands-on AI and API testing. Experiment with AI for documentation, test scenario generation and data cleanup. Learn basic API testing with tools like Postman or Salesforce Workbench so UI and backend validation are both covered.
The common thread
Across very different answers, each panelist put responsibility on a named person:
a tester who curates
a business analyst who owns first-pass QA
an architect who invites QA to design
a developer whose work isn't done at merge
a human who owns what the AI produced
Thinking through how to test your Agentforce agents or Salesforce flows? We're happy to talk it through. Get in touch with TestZeus.
// Start testing //
