How QA Testing Agents Build a Map of Your Product

Inside the knowledge graph that lets QA agents understand, remember, and test your application like a human would.

Artificial intelligence has developed very rapidly. Today, we wake up to a new AI headline almost every day. Along with these developments, the number and adoption of AI coding tools have also increased significantly. People can now create a product’s MVP in hours and launch the product live in weeks but software testing hasn’t kept up with this pace.

With this acceleration, the bottleneck has shifted to the QA side. New features can now be added in hours, but they can’t go live until we’ve verified they actually work. When that testing is manual, releases start piling up behind it.

The first solution that comes to mind is test automation. However, scripted tests written with tools like Selenium or Playwright don’t fully solve the problem. Because these tests are tied to elements on the UI with selectors, they break with the slightest interface change. Therefore, the team spends extra effort both writing tests and fixing them with every UI update. The bottleneck doesn’t disappear, it just changes form.

QA.tech solves this with an approach called agentic QA: QA agents that examine the product, build a map of it using a knowledge graph, and test it the way a human user would. These agents automatically examine the product, build a map of the product using knowledge graphs, and then, much like a human navigating a website, they navigate the product and automatically perform the necessary tests. Because they don’t use scripted testing structures, they keep working without being affected by DOM and selector changes. They also keep the map constantly updated by running an iterative process and take actions accordingly.

What Is a QA Testing Agent?

QA testing agents are essentially AI systems that perceive an application, plan its own steps, and execute them to achieve a given objective. QA testing agents don’t receive a list of steps, but rather an intent, much like telling a human to “test this flow.” Therefore, they examine the product as a human would. For example, “complete a product purchase flow” is an objective. The agent itself determines which button to press and which form to fill out to achieve this objective. This is the core of agentic QA — instead of scripting steps, you give the agent a goal and it plans and executes the test itself.

In classic end-to-end testing frameworks, engineers need to pre-code each step. For example, strict rule-based code is used such as “Click on the element with this ID, type this in this field.” The script executes these commands blindly without ever seeing the application; therefore, it crashes when the selector changes.

QA testing agents are goal-driven and work in the opposite way. The agent looks at the screen at each step and decides on the next action based on what it sees at that moment. While the script will give an error if the login button moves or its ID changes, the agent sees the button on the screen and clicks it. This is because the agent is tied to its target, not to the elements in the DOM. Therefore, the real difference here is not actually better-written code. In classic automation, the intelligence of the test is only as good as the code the engineer wrote beforehand. On the agent side, however, there is a decision-making mechanism that works at each step.

For this decision-making mechanism to work, the agent needs to understand the application. QA testing agents do this visually, just like a human. Instead of sticking to the source code of the page, they look at what’s on the screen and perceive buttons, forms, etc., as a user would.

So how does the agent know the way to the goal? A human can predict that the shopping cart will be in the upper right corner of a new site because they have a map based on past experiences. Agents need a similar map. This is where knowledge graphs come into play.

What Is a Knowledge Graph (and Why Do QA Agents Need One)?

In their simplest form, knowledge graphs are organized representations of entities and the relationships between them. The important point here is that they don’t just store information; they also store which information is related to what. For example, when you search for a celebrity on Google, the information box that appears on the right is fed by a knowledge graph. It shows information like: Person X → played → Movie Y. For a web application, nodes represent pages, buttons, and forms; edges represent transitions such as “clicking this button takes you to this page.” In this way, a map of the application is created.

So why do QA testing agents need knowledge graphs? As we mentioned in the previous section, even a user on a new e-commerce site knows that the shopping cart will be in the upper right corner. This is because they have a mental map formed from their experiences on hundreds of sites. A knowledge graph gives the agent exactly this intuition, a structured memory of past observations. An agent without this memory would have to rediscover the application from scratch every time. Thanks to graphs, they act knowing what they have seen before.

The agent needs to translate the given objective into a walkable path on this map. For example, when we say “test the checkout flow,” the agent needs to connect the intent in this sentence to concrete nodes in the graph. Two structures work together for this:

1. Graph: Provides the structure. Which page is linked to which button, and where to go after a certain action.
2. Embedding: Provides the meaning. Each node in the graph is also represented as a semantic vector.

The agent uses graphs and embeddings together to find the nodes closest to the intended checkout using semantic search, and then traces the route to the target by following this connection via the graph.

But how is the map that enables all this drawn? Nobody manually provides the agent with the application schema.

How QA Testing Agents Build a Knowledge Graph of Your Product

In QA.tech, when you give a product to a QA testing agent, that is during the onboarding phase, the agent begins autonomous exploratory testing, navigating the product as a new user would. It navigates through pages, examines forms, and learns navigation patterns. The output of this exploration process is the knowledge graph, or map of the product, mentioned in previous sections. As the agent navigates, each page is recorded as a node and each transition as an edge.

To illustrate this process, I’ll use one of my own projects: I developed a small application that collects AI news and runs on Streamlit. I gave the application’s URL to QA.tech and left the rest to the agent.

Image: The discovery scan initiated by the agent during onboarding

Once the crawl is complete, the agent now has the application’s initial map. While a simple crawler normally only follows links, the agent also interacts. Thanks to the agent’s interaction, the map includes not only pages but also dynamic content that the crawler would never see, such as hidden modals, dialogs that open when a button is clicked, and form states. QA.tech describes this structure as ‘sitemap on steroids,’ and that’s precisely where the difference lies. While the sitemap tells you which pages exist, the knowledge graph tells you what can be done on those pages.

My application is a small but clear example of this. There are no second pages to crawl, but the map is still not empty. Because the nodes are not just pages. Filters, date picker, resource dropdown, and refresh button each take their place on the map as nodes that the agent can interact with.

Image: The agent’s view of my application, with the detected interactive elements highlighted

Each element marked on the screen is represented as an Action node on the map. However, these nodes don’t exist in a vacuum; the map isn’t a flat grid, but has a hierarchical structure: Project → Feature → Page → Action. At the top is the product itself, below that are the features, below those are the pages, and at the bottom are the individual actions. This layered structure provides the agent with significant flexibility. When a bird’s-eye summary is enough for context, the agent looks at the higher layers. When it needs a detail such as “which fields are included in this form?”, it moves down to the lowest layer. This way, the agent does not have to carry the entire map for every decision; it retrieves only the level of detail it needs.

The discovery process I’ve described so far might have given the impression that the agent learned everything from scratch. But in reality, it starts with prior knowledge from similar sites. It already knows how e-commerce sites are generally set up, how login flows work, and how a form is typically filled out. As we mentioned in previous sections, even when people enter a new site, they can predict where the cart is because they have a mental map based on hundreds of sites. Prior knowledge is the product equivalent of this mental map. The agent combines its own discoveries with this prior knowledge to create the map much faster and more accurately. It’s no coincidence that the agent, seeing my application for the first time, instantly recognized the filter panel or the date picker; it’s a result of having seen thousands of similar interfaces before.

The generated map is dynamic; it’s not created once and then forgotten. Every new test and discovery updates and enriches the graph. As new features are added to the product, the QA testing agent discovers them and incorporates them into the map. Additionally, domain rules, edge cases, documents, etc., provided by the user via chat are also added to the graph. Therefore, the agent is not only fed by what it sees but also by additional information provided by the user. This iterative process ensures the map is always up-to-date.

How QA Agents Run Tests on the Knowledge Graph

Now we have an up-to-date product map. So how does this map translate into a real test? There’s a critical point here: the map isn’t just an inventory; it’s also a source from which tests are generated. The agent looks at the graph and extracts objectives, that is what a user should be able to achieve with the product. On an e-commerce site, a user should be able to log in, search for products, and complete a purchase. These are all objectives and form the basis of test scenarios. Run continuously, they become a regression test suite that grows with the product instead of decaying with it. So you don’t have to think from scratch about what’s worth testing. Of course, you can add your own tests if you want, but you don’t need to write a script; you just need to describe them in natural language in the chat.

In my own application, the process worked exactly like this. After analyzing the site, the agent automatically identified testable features. These included news feed viewing, filtering by date, filtering by source, and feed refreshing. Then, it generated a test case for each of these. I had a working test suite before I even defined a single test.

Image: The test cases generated by the agent after analyzing the application

In the real world, tests are not independent of each other, just like in our example. Consider a CRM application. First, you log in, then you create a new deal, you verify that the deal is visible in the pipeline, and finally, you delete it. In QA.tech, this chain is established in exactly the same way. The key point here is that each test starts from the saved state of the previous test. The agent doesn’t log back into the application for each test; it takes over the existing session and continues from where it left off. This is actually the same way a human QA engineer works; nobody closes the browser and re-enters the application for every test case, they progress within the flow.

So, what happens behind the scenes when you run a test, and what do you see? The agent plots the target on a graph and executes it step by step. During this process, each step is recorded. This includes which action was taken, a screenshot and video of the action, console and network logs, etc. When the test is finished, the agent doesn’t just say “passed/failed,” it writes a report describing what it observed in its own words. Look at the date filter test in my application. The agent opens the browser, goes to the homepage, clicks on the date field, enters a range covering the past week, and verifies that the listed articles fit that range, etc. The most interesting part of the report is the ‘Notes & Hypotheses’ section. The agent even hypothesizes that the application defaults to displaying the last week’s range. So, it’s not just testing; it’s making inferences about your application’s behavior.

Image: The details of a test run: the steps, the agent’s evaluation report, and the final screenshot

The real impact of this entire structure becomes apparent when the application changes. Let’s look at a concrete example. You have a test that says, “Verify that the deal appears in the correct pipeline stage after moving it to the next stage.” One day, the team adds a new column to the pipeline. In a scripted world, this test would most likely fail because the column’s position would be important. In an agentic world, however, the test continues to live on. Because the test is tied to the target, not a column. When the UI changes, the crawl and test interactions update the map, the agent sees the new layout, and reaches the same target via a new path. This goes deeper than what most tools call self-healing, which usually means remapping a broken selector to a nearby element. The agent re-reasons the entire flow from the goal, so the test survives layout changes, not just renamed IDs. To summarize this transformation in one sentence, the test maintenance cost has been shifted from the engineer’s shoulders to the map. Moreover, this map is not limited to a single web page. In a signup test, the agent can read the verification email from their dedicated inbox, click the link, and verify that the account has been activated. The same agents run on every pull request, so a full regression pass happens before code merges rather than after it ships.

Why This Matters for the Future of QA

Let’s return to the problem at the beginning of the article. Writing code has sped up, but testing hasn’t kept pace. The real promise of the knowledge graph approach was to make the product itself a continuously testable entity, rather than simply automating individual tests. As long as the map stays up-to-date, the tests stay up-to-date; your test suite evolves with you as you develop the product.

This is the shift that separates agentic testing from the previous generation of AI testing tools: we’re moving from writing tests line by line to describing them. You state the intent, the map knows the way, and the agent follows. Even for my small Streamlit application, this difference was tangible; I gave a single URL and within minutes I had a self-updating test suite. As the scale grows, with dozens of developers deploying every day, it’s not hard to imagine what this difference means. If you want to see this approach in your own product, you can start like I did: give QA.tech a URL, and leave the rest to the agent.

I hope it was useful.Don’t forget to follow me, clap me 50 times and leave a comment. If you want to check out my other articles:

[embed]Let the Agent Complain: A Feedback Loop for Better AI Tools Why agent complaints can become a feedback loop for better AI testing tools.medium.com

[embed]How Agentic QA Works: Knowledge Graphs as Memory for Test Agents How knowledge graphs give AI testing systems the product context they need to create more relevant, intent-based tests.medium.com

[embed]Claude Sonnet 5 Is Not Just a Better Model. It’s a Cheaper Execution Layer Benchmarks, pricing, and what the Claude Sonnet 5 vs Opus 4.8 comparison means for agentic AI costsmedium.com