Build a useful chatbot test set

Describe the expected behaviour first

Create a small table with the visitor’s question, the approved source and the behaviour you expect. Sometimes the expected result is a direct answer; sometimes it is a clarifying question or a handoff. Write this expectation before running the test. Otherwise, a fluent answer may persuade you to accept behaviour you never intended. Include any facts that must appear and any unsupported promise that must not be made.

Use realistic questions from your chosen business scope. Include a straightforward request, a differently worded version and a message with missing context. For example, a delivery question might omit the destination or refer to an unnamed order. The expected response should reflect what the bot can actually know. Do not mark an invented order status as helpful merely because it resembles the answer a visitor hoped to receive.

Include the cases that should not produce an answer

Test questions outside the published scope and requests for actions the bot cannot perform. Ask about an unavailable product detail, an exception that needs approval or a change to a particular account. Check whether the response states the limitation and gives a genuine route forward. The test is not whether the bot can always keep talking. It is whether the conversation remains accurate about its information and capabilities.

Include prompts that ask the bot to ignore its approved information or reveal material that should not be public. Use harmless fictional test data and a controlled environment. Record the observed behaviour and the intended boundary without assuming that a handful of examples proves complete security. Where real accounts or customer records are involved, the implementation needs its own access and data-handling verification beyond the editorial test set.

Record failures and retest the change

For each case, keep the actual answer, the review date and a short note about any gap. Classify the issue in a useful way: wrong fact, missing condition, unsupported action, unclear handoff or language mismatch. Avoid a single unexplained quality score. Specific issue types tell the owner whether to fix the source content, adjust the conversation design or investigate the underlying implementation.

After a correction, rerun the failed case and a few related cases. Check both languages if the change affects shared facts or behaviour. Keep a clear distinction between a local demonstration and the deployed service that visitors will use. A successful test in one environment does not show that contact delivery, account separation or a published widget works elsewhere. Finish with an explicit list of accepted behaviours and remaining gaps so launch decisions have concrete evidence.

Keep one small regression set of cases that previously failed. Run it after changing a source or conversation rule and retain the results. This makes it easier to notice when fixing one answer unexpectedly changes another, while keeping the review tied to specific observed behaviour.

Sources

• NIST AI RMF: documenting test cases, limitations and evaluation

Sponsored