In most businesses, testing a chatbot means three questions and a satisfied nod. The owner types whatever comes to mind, the bot gives a nice, fluent answer, and it goes live. But customers ask differently than the owner does, the price list changes in the meantime, and the platform swaps out the model under the bot. A bot that answered flawlessly on Monday then, on Thursday, promises a discount nobody offers.
I don’t hand over a chatbot after a test like that. Before it talks to its first customer, I test it on real data, which is something different from chatting with it for a while. In early September 2026, Praveen Rajasekar published a good framework for doing these tests systematically, in an article for the Google Cloud Tech account on X. He described six ways to test AI agents. They’re aimed at developer teams, but each of the six tests has a counterpart for a small business chatbot. The methods are Google’s; the small business translation is mine.
Why isn’t trying the bot a few times enough?
A few test questions only show that the bot can answer. They don’t show whether it saved the contact, avoided promising anything off the price list, and will behave the same way next month. According to Rajasekar, reliable operation needs systematic, measurable tests, not “vibe checks.”
The most treacherous sentence in his article is about success. According to it, an agent can report that it’s done even when it took an unauthorized step or reached for the wrong service. With a chatbot, it looks innocent: it writes “your appointment is booked,” and there’s nothing in the calendar.
Golden set (golden dataset)
A list of your customers’ real queries and the bot’s past slip-ups. Each query notes what the answer must include, what it must not include, and whether the bot should hand the conversation to a human. All the tests below run on this set, and you rerun it after every change.
A bot that passed once has been tested for one day, one model, and one version of your materials, and that’s all.
I’ve listed what needs to be ready before the bot says a word (source materials, handoff to a human, data protection) in a pre-launch checklist. This piece covers the other half: how the finished bot behaves. Six tests on one page:
| Test | What it checks | How to run it without a developer | When to repeat it |
|---|---|---|---|
| 1. The data arrived complete | contact, fields, tag, booking link | a test conversation, then a field-by-field check of the CRM | after changing the form, an integration, or the model |
| 2. Only your facts | prices, deadlines, and terms, not a word more | the answer next to your price list, every claim traced | after every update to your materials |
| 3. Steps in the right order | verification, booking, handoff to a human | the conversation transcript, steps ticked off | after changing bookings or handoff rules |
| 4. Quality by the scorecard | tone, politeness, whether the request was met | a pass or fail verdict and one sentence why | before launch, then on a sample of real conversations |
| 5. Old versus new version | what a change of model or instructions broke | the same queries to both versions, compared blind | with every change of model, instructions, or knowledge base |
| 6. Known tricky cases | that an old mess hasn’t come back | the full golden set with expected behavior | after every change and with every new slip-up |
Test 1: everything arrived where it should
The first test checks what was left behind after the conversation, not what the bot said. Google starts with it and gives a simple reason: before you ask another AI about answer quality, check the basics cheaply, with a plain rule. For developers, that means correct data formats and required fields; for a small business chatbot, it means whether the conversation produced a usable contact.
Anyone can do it. Write to the bot as a customer, ask for advice, and book an appointment. Then open the CRM and go field by field: the name in the name field, the phone number in the phone field, the email in the email field, the right tag, and a booking link that actually opens the calendar. Nothing gets graded here; it either matches or it doesn’t. Repeat the test every time the form, the CRM integration, or the bot’s model changes.
Test 2: the bot says only what’s in your materials
The second test makes sure every claim in an answer is backed by your documents. Google calls this groundedness and suggests measuring it with a score from zero to one. According to Google, an answer below a strict threshold gets discarded before it reaches the user. Rajasekar adds an honest line: you can’t guarantee that made-up answers never happen, but you can steadily reduce them.
Without a developer, you do it with your price list open in a second window. Go through the questions about price, delivery time, cancellation, and shipping, and underline every claim in each answer. Then find it in your materials. Whatever you can’t find there is an error, even if it sounded reasonable and happened to be right. Next time it might not be.
A bot connected to a live source changes its answers with every website update. That’s why this test belongs with every change to your price list, terms and conditions, or knowledge base.
Test 3: the right step in the right order
The third test follows the path to the result rather than the result itself. Google wants to see that the agent verified who it was talking to before it started issuing refunds, and that it checked permissions before changing anything. Unnecessary steps and going around in circles should count as errors.
For a chatbot, there are three steps: verification, action, and handoff. Before rescheduling or canceling an appointment, the bot should verify who’s writing. Before offering a discount, it should find out whether the customer qualifies. And when it hits the handoff line, it should pass the conversation on before promising anything.
Go through the transcript of a test conversation and tick off, step by step, what the bot did and in what order. This matters most for a bot that answers for you even on your Friday off. The handoff has to work even when nobody on the other end replies right away. Repeat the test after every change to bookings, cancellation terms, or handoff rules.
The stranger’s booking test
Book an appointment from one contact. Then, from a second test contact, tell the bot you want to cancel it and give the first contact’s name. If the bot cancels the appointment without verifying, the test has failed, however polite its reply.
Test 4: quality by the scorecard, not by mood
The fourth test grades how the bot answers: tone, politeness, and whether the customer got what they wanted. For grading quality, Google uses AI judges, meaning smaller models with a strict scale from one to five. Each score has clear criteria, and the judge has to write its reasoning before giving a score.
AI judge
A language model that grades another model’s answers by the rules you give it, instead of writing answers to customers. It saves time as conversations pile up. But you can trust it only as far as its verdicts match yours.
For a small business, I recommend a simpler route that Hamel Husain describes in a 2024 piece. Instead of a scale, you give a pass or fail verdict and add one sentence explaining why. Husain writes that scores on a scale take more work than a simple yes or no. The scorecard then needs just three columns: query, verdict, and reason. Anyone who knows your customers can fill it in.
If you want to hand grading over to AI, first have it grade the same answers you graded and compare the verdicts. Husain advises tracking how closely human and model verdicts agree, and checking that agreement regularly afterward, too. Fill in the whole scorecard before launch, then repeat the grading on a sample of real conversations.
Test 5: what happens when the platform swaps the model?
The bot may start answering differently, for better or worse, which is why the old and new versions run side by side. Before swapping a model, Google recommends having both answer hundreds of real queries. A judge then picks the better answer, and the system alternates the order so the judge doesn’t drift toward picking whichever came first.
And the change doesn’t have to come from you. Anthropic, one of the big providers, describes how this works in its documentation (as of October 10, 2026). It doesn’t modify a model under a given identifier and releases new versions under new identifiers. At the same time, it acknowledges that infrastructure changes occasionally alter behavior slightly, even for the same model. And every model has its own retirement date, so a move to a new one will come eventually.
In 2023, Lingjiao Chen, Matei Zaharia, and James Zou showed this isn’t just theory. The March version of GPT-4 identified prime numbers with 84% accuracy; the June version managed only 51%. Other tasks improved instead. Behavior simply shifts in both directions.
A small business doesn’t need a tournament across hundreds of queries. In my view, a few dozen queries from the golden set are enough, with both versions side by side and a person who doesn’t know which answer is the new one. Run this comparison with every change of model, the bot’s instructions (the prompt), or the knowledge base.
Test 6: known tricky cases after every change
The sixth test holds the previous five together. Google calls it a golden regression set: real user queries and past tricky cases that get run every time the code changes. If someone edits the instructions and the score drops, the check turns red before a customer notices.
For a chatbot, that means adding every slip-up to the golden set. If the bot once promised free shipping you don’t offer, that query belongs in the set, along with a note on what the bot must not say. Husain puts it plainly: whatever reading real conversations uncovers should be added to the tests. The set then grows with the business, and an old error can’t quietly sneak back.
The golden set needs an owner, like any other AI responsibility. Someone at the company runs it after every change, goes through the results, and records new cases. It doesn’t have to be a developer; a person who knows the customers and their questions is enough.
What tests can’t guarantee, and where less will do
Tests won’t produce a bot that never makes a mistake. They reduce the number of errors and, above all, make sure the same errors don’t come back. Husain adds a useful point: you don’t need to pass 100% of the tests. How many errors you can live with is, in his view, a business decision. You can tolerate more on opening hours and almost none on prices and bookings.
Not everyone needs all six tests. If your bot only covers opening hours and a few answers that don’t change for a year, a small-scale version of tests two and six will do. The full set of six is for a bot that books appointments, writes to the CRM, or talks about money. There, one wrong answer costs more than an afternoon of testing.
The whole testing process in a nutshell
- Build a golden set from real queries and describe the expected behavior for each one.
- After a test conversation, check in the CRM that the data arrived complete.
- Trace every claim about prices and terms back to your own materials.
- Go through the order of steps and try to cancel someone else’s appointment.
- Grade answers with a pass or fail verdict and one sentence why.
- After every change to the model, instructions, or materials, rerun the whole set and add any new slip-ups.
Three questions and a nod are a good start. They become a test only once they grow into a set you run after a price change and after a silent move to a new model, and each time, you know what shifted. You can then safely let a bot like that answer even during hours when nobody reads its conversations. If you’d like, I’ll build a golden set from your real queries and test your bot on it before launch, as part of an AI rollout. I’ll hand over the set and the scorecard, so you can run the next round of tests yourself.
