Back to blog
GenAI is changing software development faster than any tooling shift we've seen in years. More code gets written, more features ship, and the surface area QA has to cover grows along with it. The result is simple: teams need to run more tests, not fewer, and they need a clearer picture of what was actually verified before a release goes out.
At the same time, a new kind of testing is showing up next to classic automation. AI agents can now take a goal, explore the application, decide what to check, and report back. This is what people mean by Agentic Testing, and it may produce a different shape of results than a typical Selenium or Playwright run.
The Shift from Traditional Automation to Agentic Testing
QA teams now have to deal with 3 layers of test automation, often at the same time:
The classic automation you already have. Years of Selenium, Cypress, Playwright, JUnit, TestNG, PyTest, and the like, running in CI. None of this is going away.
New classic automation that LLMs help you write. Modern models are very good at producing tests for these same frameworks. The volume of generated test code is going up, and it has to land somewhere your team can review and trust.
Agentic automation. AI agents that take a goal, decide what to verify, and explore the system on their own or follow pre-defined steps. This is a new category, with a different shape of output.
The first 2 layers produce the kind of results QA teams have been working with for years. The 3rd one looks different.
Traditional automation typically generates deterministic outputs:
passed/failed test results
assertion statuses
logs
screenshots
execution metrics
Agentic testing introduces a different category of quality signal:
AI-generated exploration paths
dynamically created validation steps
contextual observations
execution reasoning
and findings that may require human verification
Once a company starts running agentic tests in production, the practical question is the same one engineering teams always ask about a new source of data: where does it live, who looks at it, and how do we keep a record of what it found?
Teams need to understand:
what exactly was tested
why the agent made certain decisions
what evidence was collected
whether findings were accepted or rejected
how testing evolved over time
That record matters more, not less, when the system under test is helping write the tests.
How ReportPortal Centralizes Agentic and Automated Testing Results
ReportPortal has always given automation teams answers to "what failed and where." Through ML-based analysis and manual classification (e.g. what is Product Bug, Automation Issue or Environment issue), it also helped teams build up an answer to "WHY." Modern LLMs are getting very good at the "why" question on their own. What they don't give you on their own is a place where that reasoning is written down and stays written down. That's the part teams still need: a record of what the agent did, what it found, and what the human decided to do about it.
ReportPortal already integrates with most of the popular test automation frameworks teams use today. Any modern LLM knows these integrations, which means it can wire your reporting into existing test suites or into a new framework it generates for you with very little friction. You don't lose what you've built, and you don't slow the AI down when it produces something new.
What changes now is that ReportPortal also accepts results from a second type of source: agentic runs. The same project, the same launches view, the same history, with classic and agentic results sitting side by side. Manual results are next on the roadmap, which closes the loop on the three layers of test activity a team actually runs.
Starting with version 26.0.3, ReportPortal supports ingestion of results from agentic testing systems.
This means our clients can now:
collect agentic testing results alongside classic automation launches
centralize evidence from multiple testing approaches
analyze AI-generated findings in a unified view
and maintain historical traceability of AI-driven testing activity
Agentic runs stop being a side experiment and start being part of the same pipeline your engineers already work in thanks to ReportPortal.
Product teams can now see:
which features were validated by automated tests
which user flows were covered by AI agents
how releases were tested over time
how successful those validations were across different testing methodologies
When automation and agentic results live in the same platform, the same view that a team uses to track its own work can also roll up to a stream, a portfolio, or a whole department. The question "are we ready to release?" gets the same answer whether you ask it at the squad level or in a leadership review.
Benefits of Agentic Testing for Business and Engineering Teams
For QA and engineering leaders, here is what that buys you in practice:
Unified Quality View
One place to look at classic automation, LLM-generated tests, and agentic runs. Release readiness becomes one view instead of 3 dashboards or tools.
Traceability
Agentic results link to the same builds, releases, requirements, and defects as your existing automation. You can trace a finding back to the change that caused it the same way you always have.
Governance and Human Review
When an agent runs a test, you see what it did, what evidence it captured, and what reasoning it used to get there. A human still can decide whether to accept or reject each finding, and that decision is recorded next to the run. The audit trail is the same shape you'd expect from any other test, just with an extra layer of agent reasoning attached.
Faster Adoption of Agentic Testing
Teams don't have to pick a moment to "switch on" agentic testing. You can start with a few suites, see them next to your existing runs, and scale up when the results earn the trust.
Example Workflow: Agentic QA + ReportPortal
A practical example of this workflow can be seen with Agentic QA integration.
In Agentic QA, testing is organized around Check Suites. A Check Suite is a small unit of validation that tells the agent what to verify.
The workflow typically looks like this:
A testing session is launched.
The AI agent receives a text-based objective or validation request.
The agent analyzes the goal and decomposes it into executable steps.
![Agentic QA flow]()
It dynamically navigates the application and performs validations.
Evidence and execution artifacts are collected automatically.
Results are pushed into ReportPortal for centralized analysis.
Inside ReportPortal, agent-generated activities appear as structured execution data. The dynamically generated steps produced by the agent are represented as nested steps with their own statuses, execution logs, and screenshots. To integrate your own agentic testing workflows with ReportPortal, explore the reporting documentation.
Engineers see the final outcome and the steps the agent took to get there, including what it decided to check and why.
Agentic QA is one example. The same reporting model works with any agentic testing pipeline your team builds or buys.
From Automation Reporting to Quality Intelligence
With agentic results supported alongside classic automation, ReportPortal becomes the place where all three layers of test activity meet: the suites you already run, the new ones LLMs help you write, and the agentic runs that decide what to check on their own.
Manual testing is the next piece we're releasing. It might look like a step backwards, but it isn't. Manual testing is the baseline: every test, every check, every verification a person designs is part of your test library, and that library is what your requirements hang from. Requirements tied to tests, tests tied to the runs that exercised them.
ReportPortal has always been able to identify a specific test across runs through uniqueID and testCaseID. With the upcoming release, that library will show up as its own collection. Whatever you've already built in classic automation gets documented in the same place where new generations of tests, classic and agentic, get reported.
The point isn't to pick one type of testing over another. It's to keep an honest record of all of it: what was tested, by whom or by what, with what evidence, and what your team decided to do next. That record is what ReportPortal has always been for, and it's what it keeps being good at as the way tests get written keeps changing.
Out of everything happening in the SDLC right now, testing is probably the part GenAI is disrupting the most. That isn't because testing becomes optional. It becomes the opposite: when code can be generated faster than people can read it, testing is what's left holding the line. In a real sense, testing is turning into the constraint, and that constraint has to be backed by tooling that can keep up.
ReportPortal has been around long enough to become a familiar piece of the test automation stack, mostly because it standardizes and unifies whatever shape of automation results you throw at it. As the testing world moves, ReportPortal moves with it, and the features we add are aimed at one thing: helping your company go through this modernization without losing what came before.
We're not asking you to drop everything and switch to a new tool, throwing out years of work your teams have done. We're offering a way to carry what you already have into what comes next, with one record that runs across both.