Inside the Mind of a QA Testing Agent

A good QA engineer brings much more to the table than the knowledge required to perform testing tasks. Ask them what it means to actually “know” a product, and most of them will describe something close to muscle memory. They know exactly which button opens a modal, and which one just looks like it should. Similarly, QA agents that perform testing need to be equipped with system knowledge before they can offer anything more than a fixed script. They need to understand how the product works, how a user interacts with it, and how features change after those interactions. QA.tech relies on a similar approach. Instead of bolting a test runner onto a finished product, it first builds something closer to a mind map, and then tests from there. How Speed Broke the Old Way of Testing AI coding tools have significantly reduced the time required to develop features. What used to take days now takes a couple of hours. PRs are processed swiftly, deployments take place frequently, and with each sprint, the scope of what needs to be tested expands. Meanwhile, testing is still built around the same approach that hasn’t changed much over the last decade. Script-based tools like Selenium or Playwright rely on selectors (IDs, class names, and XPath expressions) to find elements on a page. This works fine until a member of the front-end team changes a div's name while performing a Tailwind refactor or restructures the component tree for functionality. The expense approval flow still works as intended. It’s just that the tests have lost the selectors they’ve been told to find. Fixing this is far from easy. Someone has to notice the failure, figure out whether it's a locator issue or a real bug, track down the new selector, and patch the test. The obvious answer here is “self-healing” automation; that is, the tools that detect a broken selector and remap it to the nearest matching element. Sure, that might patch a renamed div, but it's still the same fixed-step approach underneath, and it falls apart the moment a whole flow (rather than just one element) gets redesigned. As you can see, we have a pretty strong opinion on self-healing as a fix. Unsurprisingly, it's not a flattering one. Read why here. Agents Follow Goals, Not Scripts A scripted test follows a path that’s been written in advance. It describes exactly what needs to be done to get the result: Click this button, introduce this value, submit the form, check the result. It carries out those instructions every time, assuming the UI looks as expected. Two ways to test. A script runs the same fixed steps every time. An agent reads the screen and adapts until the goal is met An agent starts with a goal instead: Verify the generated expense report. Then it finds the way to achieve this, based on what’s currently displayed by the app. Scripted testing follows certain steps while assuming that the UI will look as expected. QA.tech's QA agents test by user goal rather than by script, relying on the knowledge graph for the context. Scripts follow the same steps every time, while agents adapt to whatever they see on the screen. Just because a button has moved or a new form field has appeared, that doesn’t mean the test needs to be rewritten. The goal remains the same, and the agent simply needs to find a different way to get there. Why Agents Need a Product Map But, once you stop providing an agent with every step, how does it know where to go? It can't rediscover the entire product from scratch every time it runs a test. That would make it slower than a human, and we need it to be much faster. What the agent needs is a model of the app, showing it how different parts fit together, what they do, and what each interaction leads to. Such a model needs two things: Structure: How pages connect, where each action leads, what a given form breaks down into, and what happens after each interaction Meaning: The purpose of the application and the expected outcome of the actions When you combine these two, the goal like, “test an expense approval procedure” stops being abstract. The agent has enough context and knowledge to determine which pages to check, which action to perform, and what results to obtain. QA.tech calls this model a knowledge graph. This is a structural understanding of the product that carries over between runs so that the agent doesn’t have to start all over every time. The graph combines fresh crawl data with prior knowledge from similar products. QA.tech's knowledge graph documentation covers this in detail. A knowledge graph for a QA.tech project, blue nodes are pages, purple nodes are past agent interactions (source- https://docs.qa.tech/core-concepts/knowledge-graph) How the Agent Learns Your Product (Knowledge Graph) QA.tech doesn’t start by running a testing script. It actually starts with a crawling process. You give it a target URL, then set how many link-levels-deep the crawl should go. You can also narrow it down by specifying your intent, like “focus on the expense approval flow.” This is pretty useful because asking the agent to discover everything can lead to it generating a large volume of operations without necessarily producing relevant results. The crawl then follows a simple loop: Load and inspect the page as it appears to the user. Identify possible actions, including links, buttons, and form interactions. Take one of those actions, capture a screenshot of the result, and log how it got there. Score the findings against the crawl’s goal to help the exploration stay relevant. QA.tech interface showing an agent crawling an application and generating tests from the exploration For authenticated areas, the crawl can start from the saved browser state of a login test so the agent sees the app just like a logged-in user would. All this doesn’t result in a simple list of URLs. Instead, you get a graph of pages and the interactions that connect them. This gives agents enough context to understand complete workflows or focus on something as specific as a form field. And the best part is, this map is always changing. Every new crawl and test execution helps keep the model up to date with the app, so it can follow the changes as they occur instead of slowly losing relevance by staying static. From Product Maps to Test Cases After a product map is available, the agent has enough context to turn a goal into an actual test. Say this is your goal: Verify that the manager is able to authorize the report for expenses and track its paid status. Instead of transforming this sentence into a certain sequence of actions, the agent uses the product map to define what screens, controls, and transitions are required to get the desired outcome. Now remember, the test is built around the goal, not around one specific version of the UI. This is especially important when testing is part of a bigger process. A QA doesn’t normally need to log in again for every check or reset the app between the steps. They just keep going from the current state. The agent can do the same, moving through related flows while maintaining the correct state along the way. The real difference becomes obvious when the product changes. A traditional test can break if: A button is relocated to another place on the page. A new field is added to the form. The process is redesigned as a one-screen workflow. But the agent can change its approach. It re-reads the current state of the app and finds a new path to the same goal, instead of failing first and getting patched afterward. That's how QA.tech generates resilient tests that adapt when the UI is mofified. This is very different from just making a patch to the broken selector, and the product map is what makes all that possible. Without that broader context, the agent mostly reacts to the individual screens. With it, it can read a screen in the context of the whole flow. However, it still can't judge whether the new behavior is correct by design. Detailed view of a QA.tech test run showing individual steps and their pass or fail results What This Means for Your Team First of all, it’s much less dramatic than “AI replaces testing.” For daily tasks, it’s more along these lines: Traditional Workflow Agentic Workflow Write every interaction Describe the outcome Maintain selectors after UI changes Let the agent re-evaluate the path Reset and rebuild test state Reuse connected workflow state Spend time repairing scripts Spend more time reviewing coverage Treat UI changes as test failures Re-check whether the goal still works AI doesn’t eliminate the need for human review. For example, although agents are able to confirm that a transaction has reached the final Paid status, they cannot determine if that’s in line with business rules. So, the role of a QA shifts toward judgment calls. They now decide what's actually correct rather than keeping broken tests alive. There’s no need for a complete overhaul. You can simply start by monitoring one key part of your business and checking whether you still need to do maintenance as changes occur. If you decide you’d like to explore this approach, QA.tech is a reasonable place to start. FAQ What is agentic AI in software testing? In software testing, agentic AI refers to giving an agent a goal, something like "verify the expense approval flow," and letting it work out the steps on its own by reading the app as it runs. That's different from generative AI, which just drafts or patches test scripts. The agent decides what to do while the test is running, not from the instructions written beforehand. How is agentic QA different from script-based regression testing? Script-based regression testing runs a fixed sequence of selectors and assertions, so every decision gets locked in before the test ever runs, and a UI change can break the whole thing. Agentic QA makes those decisions live. The agent reads the app's current state and finds a new path to the goal when the layout changes. QA.tech works this way, testing by user goal and using a knowledge graph of the product to find a working path instead of following a fixed script. What is a knowledge graph in automated testing? It's a structured model of the app that includes its pages, the interactions that connect them, and what each action actually leads to. Think of it as the agent's memory of the product, built by crawling the app and combined with what it already knows from similar products. That’s also why it doesn’t have to rediscover everything from scratch on every run. Are self-healing tests the same as goal-based agentic testing? Not quite. "Self-healing" covers a pretty wide range. At the shallow end, a tool just remaps a broken selector to the nearest matching element and keeps running the same scripted steps. Goal-based agentic testing goes further than that. The agent re-reasons the whole flow against the new UI. As a result, it can handle the modified workflow, not just a renamed button. Are AI test automation tools reliable? They're reliable for checking things you can actually observe. For instance, they can verify that a form has been submitted, a state has changed, or an expense report has reached Paid status. They can also adapt when the UI changes. What they can't do is judge whether new behavior is in accordance with business rules. That call is still up to your team. In practice, agentic testing doesn't remove the need for QA teams. It simply enables them to spend more time on review and judgment.