How to Build a Test Dataset for an AI Feature

Once you have a prompt, you need something to run it against. That is your test dataset: the set of inputs you use to see how the feature behaves before you ship it. A good test set is the difference between a feature that looks fine in a quick check and one you can actually trust.

Replicate how a user would use the feature

The starting point is to replicate how a real user would use the feature. Build the little pieces that make up a real interaction. For a course explainer, that is a lesson, a user, and a question. For a voice-note feature, it is the user's raw note converted to a text string. Each test case is one user input, and you save them one at a time.

Start with three to five cases that cover the normal, expected use. If you already have questions in mind that users would ask, use those.

Then try to make it break

The happy path is not enough, because you do not control what users send. The point of the rest of the test set is to push the feature into the situations it will actually hit in the wild.

Add an input in another language. For an international audience, test a question asked fully in another language, not just one foreign word mixed in. Add a note that mixes two things, like a shopping list and a task in the same message. Add an input where the user misunderstands the feature and asks about something unrelated. Add a recording that accidentally captured something off-topic, like "hey, how are you," and check that the feature recognises it as not related.

For anything built on voice, remember the transcription itself can introduce errors. A brand like Pepsi might come through as something else, and there will be words with typos in the input. Adding cases like that shows you how the models handle imperfect text.

You can always extend it later

You do not have to capture everything up front. You can start with the selected phrase or the raw note, run it, and then extend the test data when you realise you also want to include something about the user, or the history of what they did before. The test set grows as you learn what matters.

A practical habit that strengthens it: when you find the model getting something wrong, like the date, you fold that case back into the test data with the missing detail filled in, and that becomes part of the next iteration. The test set is not a one-time setup. It is the thing you keep sharpening as you find new ways the feature can fail.