SYSTEMATIC LITERATURE REVIEW · QRS 2026

Reliability of
LLM-Based Testing Agents

Architectures · Threats · Mitigations
Jaakko Tyynelä  ·  Janne Parkkila  —  LUT University
press → to begin
BACKGROUND

These days, LLM agents write tests, track down bugs, click through GUIs, reproduce security bugs — all inside real testing pipelines.

But how much can you really trust what they hand back?
THE GAP

We know what these agents can do. We know far less about when to trust them.

There are good surveys on LLMs for testing, and on multi-agent systems in general — but nobody has really put the two together and asked how reliable these agents are. There just isn’t much evidence on when, or why, their output goes wrong.

RESEARCH QUESTION
How reliable are LLM-based agents for software testing, and what architectural designs and mitigation strategies influence their dependability?
What we looked at correctness · consistency · reproducibility
What we left out security · performance · ethics
HOW WE LOOKED

How we found the studies.

0
identified
0
after abstract screening
0
full-text assessed
0
included
ACM DLIEEE XploreSpringerarXiv
Guidelines Kitchenham & Charters (2007) · PRISMA 2020
Window 2023 – Feb 2026

Kitchenham, B. & Charters, S. (2007). Guidelines for performing SLRs in software engineering (EBSE-2007-01). · Page, M. J. et al. (2021). PRISMA 2020. BMJ, 372, n71.

01

Architectures

The different ways people actually build these agents.
CONTRIBUTION 01 · TAXONOMY

The designs sort into four groups.

cardinality: single → multi-agentmodality: text → multimodal
A1
Single-agent tool-using
NIODebugger · SAINT · You Name It, I Run It
0studies
A2
Role-based multi-agent
MAGISTER · CoverNexus · IntelliTest
0studies
A3
Single-agent multimodal
Test-Agent
0studies
A4
Multi-agent multimodal
Multi-Agent LLM Committees
0studies

24 studies classified · 2 REST-API studies compare single- & multi-agent variants and count in both A1 & A2.

CONTRIBUTION 01 · FINDINGS

Most studies landed on the same kind of setup.

A2
role-based multi-agent is the most frequent pattern
0/24
are text-only (A1 + A2)
0/24
use visual perception — A4 has just one
Splitting the work across several agents is how most people try to make these systems reliable. The catch: keeping all those agents in sync is itself one of the biggest things that goes wrong.
02

Threats

Seven things that keep going wrong.
CONTRIBUTION 02 · THREATS

What actually goes wrong — and how many of the 26 studies ran into it

T1
Hallucination-driven invalid tests
Fabricated or logically wrong tests that misrepresent what the code does.
0
T2
Non-deterministic outputs
Same task, different results across runs — reproduction is not guaranteed.
0
T6
Coordination complexity
Orchestrating many agents; out-of-sequence steps break the workflow.
0
T4
False positives / negatives
Flags failures that are not real, or misses real defects.
0
T7
Environment interaction failures
Misuses external compilers, APIs and tools, or misreads their feedback.
0
T3
Prompt sensitivity
Small prompt or template tweaks swing test quality.
0
T5
Scalability & cost
Repeated generate–run–refine loops burn tokens, time and compute.
0
THE BIGGEST GAP

Everyone brings up non-determinism. Almost nobody does anything about it.

Run the same agent on the same task twice and you can get two different answers. That makes the results hard to reproduce, and hard to compare.

0
studies report it as a threat
vs
0
study actually does something about it
Just one paper — Ke et al. (NIODebugger) really tackles it, by running tests several times to catch when the results drift. Temperature 0, controlled sampling — hardly anyone uses them.
03

Mitigations

What people actually do about all this.
CONTRIBUTION 03 · MITIGATIONS

How people handle each problem — and how common each fix is

T1
Hallucinated tests
→
Multi-agent verification & consensus
0/26
T2
Non-determinism
→
Deterministic controls: repeated runs / re-execution
0/26
T3
Prompt sensitivity
→
Structured prompt & role templates
0/26
T4
False pos / neg
→
Execution-based validation — run the tests
0/26
T5
Scalability & cost
→
Modular architecture, selective generation
0/26
T6
Coordination
→
Workflow orchestration & clear agent roles
0/26
T7
Environment errors
→
Tool validation, sandboxing & monitoring
0/26
Most teams build these in from the start, rather than adding them after something breaks — 19 studies run the tests to check the output, even though only 10 mention the false alarms it catches.
STEPPING BACK

It really comes down to one trade-off.

Multi-agent role decomposition (A2)
↗
↑ Effectivenesscoverage · capability
↘
↑ Reliability riskcoordination · cost · new failure modes
And nobody has actually measured it — we don’t know how much reliability each extra agent buys you, or what it costs.
FOR PRACTITIONERS

If you’re building one of these, this is what helps.

01
Run the tests, every time
Actually execute what the agent produces. It’s the safeguard that shows up most, and it works.
19/26 · NIODebugger, CoverNexus, SAINT
02
If you use many agents, give them structure
Otherwise the overhead of keeping them coordinated eats the benefit.
MAGISTER, AI-Powered MA · [1,13,34]
03
Plug in real tools
Give them compilers, test runners and monitors so they can catch their own mistakes.
You Name It I Run It, AEGIS · [7,21,31]
04
Treat prompts like code
Version them, review them, test them — the same as anything else you ship.
Liu et al. · [21]
They’re not ready to run on their own yet — keep them inside a pipeline you actually control.
CONCLUSION

The fancier the setup, the more it can do — and the more ways it can break.

What we found
ArchitecturesRole-based multi-agent (A2) is the most common design, and 21 of 24 are text-only — multimodal is still rare.
ThreatsSeven recurring failure modes — most often hallucinated tests, non-determinism, and coordination between agents.
MitigationsRunning the tests (19/26) and giving agents clear roles are the usual fixes; non-determinism is left almost untouched.
Where next
  1. Report determinism controls by default: temperature 0, repeated runs
  2. A shared benchmark and reporting checklist — models, prompts, configs
  3. Measure the reliability each added agent buys, and what it costs
  4. Study multimodal and GUI agents beyond the single A4 case
More agents buy more capability — but at a reliability cost no study has actually measured, and non-determinism, the biggest threat to reproducibility, stays almost entirely unaddressed — just 1 of 26 studies tackles it.

Thank you

Jaakko Tyynelä  ·  Janne Parkkila  —  LUT University  ·  first.last@lut.fi
Questions?
Appendix follows →   quality assessment · study list · validity · criteria
APPENDIX · B1 · QUALITY

How we scored each study.

0avg / 6 · scored by author 1, re-checked by author 2 on a random 8
QA1
Empirical evaluation present
0/26
QA2
Comparison with a baseline / tool
0/26
QA3
Clear description of subject systems
0/26
QA4
Clearly defined evaluation metrics
0/26
QA5
Reproducibility detail (models, prompts, config)
0/26
QA6
Discussion of threats / limitations
0/26
APPENDIX · B2 · STUDIES

Every study, grouped by how it’s built.

A1Single-agent tool-using0 studies
NIODebugger (2025) · SAINT (2025) · You Name It, I Run It (2025) · Using LLMs for Requirements (2025) · Towards Autonomous Testing Agents (2023)
A2Role-based multi-agent0 studies
MAGISTER (2025) · CoverNexus (2024) · IntelliTest (2025) · Test vs Mutant (2026) · Breaking Single-Tester Limits (2025) · AI-Powered Multi-Agent (2024) · HPCAgentTester (2025) · Multi-Agent REST API (2025) · LLM Agents for Web Vulnerability (2025) · LLMFuzzTestGen (2025) · AEGIS (2025) · Hallucination→Consensus (2025) · Intent-Driven Mobile GUI (2024) · Evaluation of LLM Choice, GUI (2025)
A3Single-agent multimodal0 studies
Autonomous Web Agents (2025) · Test-Agent (2024)
A4Multi-agent multimodal0 studies
Multi-Agent LLM Committees (2025)

Counts include 2 REST-API studies (Agentic LLMs for REST API, 2025; Test Amplification for REST APIs, 2026) in both A1 & A2. · 2 secondary surveys (He et al.; Xia et al., 2025) excluded.

APPENDIX · B3 · VALIDITY

Where this could be wrong — and what we did about it.

Search completeness
4 libraries incl. arXiv; multiple query formulations piloted. No type excluded.
Selection bias
Explicit IC1–IC5 / EC1–EC5 fixed before screening.
Extraction bias
First author extracted, second verified; consensus on disagreements.
Publication bias
Positive results over-represented; arXiv captures candid limitations.
External validity
Rapid LLM evolution bounds findings to 2023–Feb 2026.
APPENDIX · B4 · CRITERIA

How we decided what counted.

Inclusion
  • IC1Proposes/evaluates an LLM-based agent on a testing task
  • IC2Empirical evaluation or concrete system description
  • IC3Peer-reviewed paper or arXiv preprint
  • IC4Written in English
  • IC5Published 2023 – February 2026
Exclusion
  • EC1LLM used only as a static, single-prompt generator
  • EC2Not related to software testing
  • EC3Secondary study without novel taxonomy/framework
  • EC4Duplicate or earlier version
  • EC5Full text not accessible
01 / 21
← → navigate · F fullscreen · S notes