Why HoardyQA is the best QA agent on the market, and how to check that yourself

Every week another product launches with the words AI testing in the headline. Most of them are a screen recorder with a language model attached. You click through your app once, it saves the clicks, and later it replays them until your markup changes and the whole suite goes red for no reason.

That is not an agent. That is a macro with better marketing.

We built HoardyQA because we kept doing the same job by hand for clients, and the hand version was better than every tool we tried. So we wrote down what made the hand version good, and turned it into five requirements. If a product fails any one of them, it is not a QA agent, whatever the landing page says.

1. It writes the test cases, not you

The first job is deciding what to test. That is the part most tools skip, because it is hard and it does not demo well. They hand you an empty canvas and call it flexibility.

HoardyQA reads the app first, then designs cases in ISTQB form: preconditions, steps, expected result, and a category. A full pass produces around 120 of them across routes, roles and breakpoints without you typing a single step. You can read the plan before it runs and you can argue with it. You do not have to author it.

If you still have to write the test cases, the tool is a runner, not an analyst.

2. It checks the result against your API, not your screen

A success toast is not evidence. We have watched a checkout return a friendly thank you page while the payment intent sat in requires_action, and we have watched an invite form save a member while the seat counter stayed exactly where it was. Both of those look perfect in a screenshot.

So every mutation is re-read at the source. After the click, the agent queries the endpoint or the row and compares what the API says with what the user was told. When the two disagree, that is the defect, and the report quotes both sides of it.

This is why we refuse to grade a run from screenshots alone. It also means our defect reports tend to arrive with a method, a status code and a response body attached, which is a shorter conversation with your developer than a paragraph describing a feeling.

3. It explores, because nobody knows their own app

Ask a founder how many routes their app has and you will get a number that is wrong by a factor of two. Features get shipped behind flags, admin screens get built and forgotten, and a route from an old sprint is still reachable if you know the path.

The first thing our agent does on a new app is walk it. It reads the sitemap, follows links, watches the network tab for calls the interface does not advertise, and records everything it finds. On one recent app the reconnaissance lane turned up a settings page that nobody on the team remembered existed. It was reachable, it rendered account data, and it had no test coverage because no human had opened it in months.

4. It learns, and the learning survives the run

This is the requirement the others cannot fake, and the reason a subscription makes sense instead of a one-off audit.

When a selector stops matching because you redesigned a page, the agent re-reads the DOM, works out what the element became, repairs the step, and writes the repair down. When a test turns out to be flaky for a reason that has nothing to do with your code, it goes on a known-flaky list so it cannot waste a future run. When a client tells us a finding was wrong, that verdict is recorded against the case, and the pattern behind it is fed back into how that project is tested.

Per project, the knowledge looks like a route map, recorded flows, a selector table with fallbacks, a flaky list, and a log of repairs. Every lane reads it before it starts. The second pass is quicker than the first, and the tenth is quicker than the second.

That knowledge stays with the project. One client's map, credentials and findings are never used to inform another client's run. Cross-customer pattern sharing would be a better product and a worse promise, so we do not do it.

5. Your credentials stay yours

An agent that tests your app has to sign into your app. That is a real risk and we treat it like one.

• Test credentials are encrypted with AES-256-GCM on our server before they are written. The database stores ciphertext, a unique initialisation vector and an authentication tag, and nothing else.
• The encryption key lives in the server environment, not in the database. A stolen database dump, on its own, decrypts nothing.
• Nothing is decrypted until a run starts, and the plaintext never leaves the worker process. It is not logged, not rendered in a report, and not returned to a browser.
• A tampered record fails to decrypt rather than decrypting to something wrong, because GCM authenticates as well as encrypts.
• We ask for a dedicated test account per role, so the credentials you hand over can be revoked without touching a real user.

Two more things worth saying plainly. We will not test a domain you have not proven you own, and destructive controls such as delete account or live payments stay excluded unless you explicitly ask for them. Those rules cost us some impressive demo footage. They also mean nobody's production data has ever been deleted by our agent.

What it is not

It is not a load test. It is not a penetration test, and it will not replace one. It is not a unit test generator for your codebase. If you want a framework to write your own Cypress specs, use Cypress, it is excellent at that.

It is one thing: an agent that decides what to test on a deployed web app, runs it, proves what it found, and remembers the app for next time.

How to check us in ten minutes

The claim at the top of this page is worth nothing if you cannot test it. So the first pass is free on your own app, and it takes about ten minutes. You get the route map and the five worst things it found, whether or not you subscribe afterwards.

If the map is wrong, if the five defects are cosmetic, or if the report reads like something a machine wrote for another machine, do not buy the subscription. We would rather have fewer customers who can vouch for the work.

The best QA agent is not the one that runs the most checks. It is the one whose report you would forward to a client without editing it.