Who Tests the AI Tester? Evidence Before Autonomy

By Bogdan Stefan Plesa

An AI testing agent has two opportunities to fail. It can fail to perform a useful experiment, and it can misinterpret the experiment it did perform. Watching it finish a login journey tells us little about either risk.

FaST, my Fully AI Software Testing proposal, explores agent-led testing workflows. That makes the testing agent itself part of the system we need to investigate. Before making a reliability claim, we need to know how it behaves across repeated trials, changed conditions, and deliberately faulty applications.

James Bach's Seriously Testing LLMs challenges confidence based on isolated demonstrations. His later Serious Data From Testing LLMs presents evidence from a retrieval experiment under multiple conditions. These are useful challenges to FaST, not endorsements of it.

The first practical question is what counts as a result. Suppose an agent disables an account and says that access is revoked. We need an observation that supports that statement: can the old session still reach a protected resource? If that probe never happened, the honest result is “not observed.” An explanation from the agent is not a substitute for the probe.

The next question is whether the testing system can detect a known failure. The FaST architectural demo includes two deliberate faults: a duplicate refund and a session that survives account disabling. Its independent checks are designed to catch those effects. A healthy fixture gives us a useful comparison.

That does not establish that the agent will discover unfamiliar faults. The fixture exposes state directly and the objective explicitly asks for the relevant probes. It is a controlled architectural exercise. A realistic evaluation must add less obvious defects, browser and API uncertainty, and cases where the correct next step is unclear.

I would record at least four separate outcomes: a faulty application incorrectly passed, a healthy application incorrectly failed, an inconclusive investigation, and an observed policy violation. Collapsing them into one “accuracy” score can hide the most consequential failure. An agent that refuses every task may appear cautious while delivering no useful testing.

For an initial experiment, run multiple fresh trials for each condition, preserve every trace, and record the exact model and prompt version. Repeat with modest variations of the objective. Report denominators and costs. Twenty-five runs may reveal variation; it does not establish a universal reliability guarantee.

A second model can offer criticism, but it can share the first model's assumptions. Where possible, use independently specified business rules and application evidence. A refund ledger, a protected-resource response, and a known fixture state provide a different kind of support from another fluent explanation.

The first FaST release provides the harness and the questions. Its deterministic tests validate a small implementation; they do not demonstrate live-model performance. The useful next contribution is a reproducible experiment, including the cases where the agent gets it wrong.

Concept and Paradigm, created by Bogdan Stefan Plesa. FaST's progress should be judged by the quality of the evidence it produces and the limitations it makes visible.

Part 3 of the FaST article series. About Bogdan Stefan Plesa. Prepared with AI assistance; technical scope and provenance are documented in source notes.

Comments

Post a Comment

Popular posts from this blog

Fully AI Software Testing: Beyond Scripted Automation

By Bogdan Stefan Plesa A login test can click the right buttons and still tell us very little about the product. It may confirm that a familiar journey works while missing the changed redirect, the stale session, or the account that should no longer have access. Writing that script with an LLM changes how we produce the script. It does not automatically change how we investigate the application. FaST, my proposal for Fully AI Software Testing, starts with a different unit of work: the testing objective. An agent receives a goal, observes the application, chooses an action, examines the result, and decides what to try next. The intended output is evidence that helps us understand the product. “Fully AI” describes the operational delegation I want to explore. It does not mean that accountability disappears. People still choose the purpose of the investigation, the environment, the permissions, and the evidence needed for a release decision. An agent completing a task is not the same a...
Read more

The Architecture of Autonomous Agents in Software Testing

By Bogdan Stefan Plesa , creator of the FaST concept and paradigm. An autonomous testing agent needs more than a browser and a prompt. It needs an objective, observations, a restricted set of actions, and a defensible way to report what it learned. In FaST, my Fully AI Software Testing proposal, those responsibilities form an explicit architecture. The reference repository implements a compact version in Python. Its application is an in-memory model, so there are no real users, orders, or payments. The purpose is to make the boundary between an agent's choices and the evidence for its conclusions easy to inspect. One decision at a time The planner receives the current application snapshot and the history of observed actions. It returns one action. The runner validates that action against an allowlist before executing it. The resulting state becomes input to the next decision. In offline mode, the planner is a fixed sequence. In model mode, LangChain requests a structured resp...
Read more

Testing User Creation, Disabling, and Stale Sessions

By Bogdan Stefan Plesa User lifecycle testing shows why adaptive investigation matters. Creation, authentication, disabling, and session revocation interact across time. A happy-path script can check every screen while missing the relationship between them. What changes Create a synthetic user and verify the durable identity, assigned role, and uniqueness rule. Establish protected access before disabling the account, preserve the session, then probe that same session immediately after revocation. The FaST standard Check every layer: UI status, identity record, fresh authentication, and established-session access. Differences are findings. The FaST reference deliberately includes a stale-session fault because a convincing workflow can easily miss it when actions occur in the wrong order. FaST: Fully AI Software Testing — Concept and Paradigm, created by Bogdan Stefan Plesa. Explore the open reference project , read about the author , and inspect the source notes and limitations . Prepar...
Read more