What Fully AI Software Testing Is—and Is Not

By Bogdan Stefan Plesa

Fully AI Software Testing is easy to misunderstand. It does not mean asking a chatbot to generate Selenium code. It does not mean trusting a model because it completed a demo. In the FaST proposal, an AI agent receives a testing objective, observes the application, selects an allowed action, examines the result, and decides what evidence is still missing.

The change is operational

Traditional automation follows a path that a person encoded in advance. An autonomous testing workflow can adapt the next experiment to what it observes. If disabling a user leaves an old session active, the agent should investigate that state instead of blindly continuing with the happy path.

The word “fully” describes delegation of the testing loop, not delegation of accountability. People still define the environment, permissions, business rules, stop conditions, and evidence required for a release decision.

What FaST does not claim

A completed task is not proof of product quality. A fluent report is not proof that the described events occurred. A single successful run is not a reliability measurement. FaST therefore separates the planner that chooses actions from the evaluator that checks consequences.

The first public implementation is deliberately modest: a synthetic account-and-order system, a deterministic replay, two injected faults, and an optional LangChain planner. It is an architectural reference, not a universal autonomous testing product.

The useful standard

The question is not whether an agent looks intelligent. The question is whether it produces inspectable evidence, preserves uncertainty, and exposes its own mistakes. A system that cannot distinguish “passed” from “not observed” is not ready for greater autonomy.

That evidence-first boundary is the foundation of FaST and the basis on which future experiments should judge it.

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 project's source notes and limitations. Prepared with AI assistance and reviewed for consistency with the documented FaST proposal.

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