Plot twist in 2026: How AI & agents will change the game and what will matter most

Hi folks,

Let’s discuss QA ass we roll into 2026, AI and testing agents are taking on more of the busy work like writing tests, running checks, watching releases :eyes:

So… what does that mean for us?

:backhand_index_pointing_right: How do you think Software QA will change in 2026?
:backhand_index_pointing_right: Which QA roles or skills do you think will become the real MVPs?

Are we talking test strategists, automation wizards, quality coaches, or some brand-new role we haven’t named yet?

Drop your thoughts, or predictions, or anything that you have been wondering :hot_pepper:

In 2026, agents will do more of the “writing/running/maintaining” work, so QA’s value shifts from creating tests to deciding what to test, what “good” means, and how we know we’re still good after every change. (Gartner)

The MVP skills/roles I’m betting on:

  • Test strategists / quality coaches: risk-based coverage, quality gates, and aligning teams on outcomes (not test counts).

  • Automation engineers who can “anchor” agent-generated tests: stable selectors, reliable flows, guardrails (the ecosystem is already moving fast here, e.g., agentic UI testing tooling). (Thoughtworks)

  • AI eval / model-quality testers: benchmarks, golden datasets, drift monitoring, and failure analysis for AI features (this is becoming formalized as a discipline). (ISTQB)

Net: the winning QA folks will be the ones who can turn AI speed into trusted releases.

what’s your opinion on this @depapp @Monty_Bagati and @dineshh

i see 2026 less as “AI agents replacing QA” and more as “AI agents changing what QA focuses on”

agents can generate and run tests fast but they still don’t understand product risk, user intent, or business context. believe me.

what will matter most is our ability to set the right quality goals, decide what’s worth automating and what’s not, and validate what agents produce
in other words, less script writing, more judgment and strategy

the last thing, AI speeds things up, humans still decide what good quality actually means

Coding would be a thing of the past and focus would be more on “decision making”.

I’m trying to set up some agent-generated tests in Katalon right now, but dealing with broken selectors is taking up way too much time. Is there a reliable way to automate those guardrails or auto-heal the selectors so I don’t have to keep fixing them manually? Thanks!

We’re currently having pain in updating test objects as well. If there is a vote for improving the process of fixing locators then I’m onboard!

I think QA will become less focused on writing individual test cases and more focused on validating business outcomes, risk assessment, and test strategy. AI can generate tests quickly, but it still struggles to understand context, edge cases, and what really matters to users.

The most valuable QA professionals in 2026 will likely be those who know how to guide AI effectively while maintaining a strong understanding of quality, automation, and the product itself. The tools will change, but critical thinking will remain essential.

Yes. There is a way to write a robust XPath locators: robust against the possible changes in the target HTML. See the following page of Katalon doc:

Method Description Example
Checking Multiple Attributes Add more than one condition to search element using XPath. //*[@id=‘btn-login’][@type=‘submit’]
Index Specify a given tag name in terms of the index value you wish to locate. Use this when more than one element is present in the DOM with similar attributes, and it becomes difficult to search for them. //div[@class=‘form-group’]//select[1]
Chained XPath Use multiple XPath expressions and chain them. //section[@id=‘appointment’]//span[@class=‘glyphiconglyphicon-calendar’]
Contains() Use the Contains() method to detect dynamic elements that contain static values. //button[contains(@id, ‘btn-login’)]
Last() Last() is a method used in an XPath expression. It is used to get the very last node. //ul[@class=‘list-inline’]/li[last()]
Start-with() The Start-with method finds the element using the starting text of an attribute. This method is useful when the first part of the attribute value is fixed (static), and the rest is dynamic. //h3[starts-with(text(),‘We Care About’)]
Preceding Select all nodes that come before the current node. //*[@id=‘btn-login’]//preceding::input
Following Select all elements in the document following the current node( ). .//*[@id=‘txt-username’]//following::input
Following-sibling Select the following siblings of the context node. .//*[@id=‘txt-username’]//following::input
Ancestor Select all ancestors (parent, grandparent, etc.) of the current node. //ul[@class=‘list-inline’]/ancestor::div
Child Select all children of the current node. //ul[@class=‘list-inline’]/child::li
Descendant Select all descendant (child node, grandchild node, etc.) of the current node. //ul[@class=‘list-inline’]/descendant::li

Unfortunately, Katalon’s tools (Record Web, Spy) are not capable to generate those “robust XPath” right away. The tools simply have no idea what is the robustness of a locator against a given HTML. You need to train your skill (of XPath or CSS Selector) and you should manualy rewite the auto-generated locators to the robust ones. If you could do the rewrites, you would free yourself from the maintenance nightmare.

No. I am sure Katalon’s tools can not do the rewrite jobs automatically for you.

I am not sure how much the AI in the world is capable (trained) about rewriting the flaky locators to the robust ones against a given HTML. I don’t know if anyone in the industry is working on trainging AI so that it is capable of that sort of work. Is Katalon working on it?

You need to learn the XPath technology by reading tutorials and documents; go through sufficient amount of exercices where you manually rewrite the auto-generated locators to robust ones. I believe that you want to learn the XPath technologies as people did in 1999 when the RFC of XPath 1.0 was first published.


I would rather recommend using CSS Selector instead of XPath. See