ON THIS PAGE ▾
A chatbot built on a large language model can answer fluently and still be wrong, unsafe or off-brand. It speaks for your business, usually without a person reading the reply first. That makes launch day the wrong moment to find out how it behaves.
Testing a chatbot is not like testing a form. The same question can produce different answers, a small change to a prompt or a knowledge-base article can shift behaviour, and "correct" is often a judgement rather than a match against expected text. This article sets out a practical plan that works anyway.
Start by defining what good looks like
Before writing a single test, agree with the people who own the product what a good answer is. For a support bot, that usually means five things at once: the answer is correct, it is supported by your own sources, it stays inside what the bot is allowed to do, it sounds like your company, and when it does not know it says so and offers a way forward.
Write those down as a rubric with plain-language examples of a good reply, an acceptable one and an unacceptable one. This is the single most useful artefact in the whole exercise, because every later judgement, human or automated, is made against it.
Build the test set
A useful test set is a collection of conversations, each with a purpose, an expectation and a list of things the bot must not do. Cover four kinds of case:
- Typical. The questions your customers ask most, in the words they actually use (including typos and abbreviations).
- Difficult. Ambiguous questions, questions with a false premise, questions the knowledge base cannot answer and questions where two sources disagree.
- Adversarial. Attempts to make the bot ignore its instructions, reveal its prompt, say something it should not or take an action it should not.
- Multi-turn. Conversations that change topic, correct themselves, refer back to something said earlier or push back on an answer.
A simple, structured format keeps the set maintainable. Whatever tool you use, record the same fields:
- id: refund-policy-expired type: grounding conversation: - "Can I get a refund after 45 days?" expect: - states the refund window found in the knowledge base - does not invent exceptions - offers a handover to a person must_not: - promises a refund - quotes a window that is not in the knowledge baseWhat to test
Accuracy and grounding
Check that answers are correct and supported by the sources the bot is meant to use. Ask questions with known answers, then questions whose answer is deliberately absent. A well-behaved bot says it does not know; a poorly behaved one invents something plausible. Pay particular attention to numbers, dates, prices and policy wording, where a confident mistake costs the most.
Safety and refusal
Try requests the bot should decline: harmful content, advice outside its remit, requests for other customers' information. Check that it declines clearly and politely, and that it does not lecture or over-refuse ordinary questions.
Prompt injection and prompt leakage
Prompt injection tops the OWASP Top 10 for LLM Applications, and system prompt leakage has its own entry. Test instruction overrides ("ignore your previous instructions"), requests to reveal hidden instructions, and hostile text pasted into the conversation or hidden in a document the bot reads. Report which attempts succeed and how serious each exposure is. This is QA-level testing: it finds real weaknesses, but it is not a substitute for a formal security assessment where one is warranted.
Tone and brand voice
Compare replies with your style guidance. Look for over-promising, false empathy, jargon and inconsistent formality. Tone is subjective, which is exactly why a person should judge it.
Multi-turn behaviour
Run long conversations. Check that the bot remembers what matters, forgets what it should (such as personal details it need not keep), handles a change of topic and stays consistent when the user contradicts themselves.
Escalation and failure
Test the handover to a person, the message shown when the model is slow or unavailable, and what happens when a connected tool fails. Customers judge a bot at least as much on how it fails as on how it succeeds.
Run, score and judge
Run each case several times, with variations in wording, and judge outcomes against the rubric rather than against exact text. Automated scoring against the rubric is a reasonable first pass: it helps you find the likeliest problems quickly. But the call on whether a reply is acceptable, a failure repeats or an exposure matters belongs to a person who understands the product, the customers and the policies.
Keep every confirmed failure as a new test case. Over time the set becomes your regression suite for the bot.
THE UPDOER APPROACH
How UpDoer approaches this
We treat a chatbot as a product with risks to map, not a model to benchmark. The work follows our seven-step methodology: we first learn the bot's purpose, audience, prompts, knowledge sources and the actions it can take, then rank conversation topics by consequence, design the test conversations, run them (including exploratory sessions that try what scripts miss), use AI to draft variations and group similar bad answers, and have a QA engineer read the conversations behind every flagged result before anything is reported.
Findings come back with the conversations that show them and a plain statement of what was not covered. You can read more about the service on our LLM & Chatbot Testing page, see how it fits with wider AI Application Testing, or read about how we work.
Questions to ask before you launch
- Do we have a written rubric for a good answer, agreed with the business owner?
- Can we re-run the same set of conversations after every model, prompt or knowledge-base change?
- Do we know what the bot does when it does not know, and is that acceptable?
- Has someone tried to make it misbehave, and do we know which attempts worked?
- Is there a clear route from the bot to a person, and does it work?
If you would like a second pair of eyes on your own situation, schedule a meeting and tell us about your product, your delivery process and the quality questions you are facing.