A voice agent is tested well only by callers who behave like callers. We call it the way real people do: with accents, noise, interruptions and questions it was never taught. We also test classic IVR menus and keypad input, and the load of many calls at once.
Different ways of speaking the same request, tested across the callers your customers actually are.
Street, car, call centre and poor lines, where speech-to-text gets things wrong.
The caller talks over the agent, corrects themselves or cuts in mid-sentence.
Unrelated questions, long pauses, emotional callers and requests the agent should refuse.
How long the caller waits after speaking, and where silence starts to feel like a dropped call.
The agent hands over when it should, passes the context on and does not loop.
Hallucinated policy. The agent states a refund rule, opening time or price that your company does not have. We ask policy questions with known correct answers and check each reply against your own documents.
Regression after a model change. A new speech-to-text, language model or voice can change behaviour without any change to your code. We keep a set of test calls and rerun it on each change, so you see what moved before callers do.
Load. Fifty callers at once is not one caller fifty times. We test concurrent calls for dropped calls, slower answers and mixed-up context between sessions.
Maria is the inbound phone agent for Arctic Works, a car-service business in Cluj that we are related to. We tested it in rounds of real test calls. It answers in Romanian, switches to English, checks open slots, books, looks up and cancels appointments, and sends a WhatsApp confirmation and a staff alert. Each round looked at three things, tuned them, and then the next round of calls ran: how the agent answers, how fast it answers, and what information it has (knowledge base, schedule data and tools).
Batching the slot lookup brought the time to first answer down to about 0.4 seconds.
We preloaded the schedule at call start, added a rule never to go silent, and a short line spoken before each tool call.
The voice platform sent parameters in a different field than its docs suggest. The same fix made the agent ask the caller's name.
Brevity rules, one question per reply, fewer slots, a business-hours check, and calls under 3 seconds filtered out of notifications.
The lesson. The agent was paused for a period and a person took the calls, to learn what callers ask. Only then were the prompts tuned on real intent.
Many of the phone systems we are asked about are menu-driven, not AI. We test them as well: every menu path and keypad (DTMF) input, wrong and missing input, time-outs, language selection, call routing and the prompts callers hear. Automated test calls cover the paths that repeat, and an engineer listens to the ones that need judgement.
The reasons people call, the policy the agent must follow and the point at which it must hand over.
Scripted and free-form test calls, with the voices, noise levels and interruptions agreed with you.
Automated calls for repeatable paths, and an engineer listening to calls where judgement is needed.
Each failure with the recording or transcript, what was said, what should have happened and the risk.
The same set runs again when the speech-to-text, language model or voice changes.
Findings ranked by risk, with the transcript of each call that failed.
The test calls and expected outcomes, so your team can rerun them after each change.
Each failure logged in BugBoard or your tracker, linked to the call.
Voice agents are language-model systems, so they also need AI red teaming for manipulation and leakage, and chatbot testing for the text channel. The wider approach is on our AI quality assurance page. For the call volume side, see performance testing.
Testing a conversational agent that talks to callers: how well it understands speech, whether its answers are right, how fast it replies, and what it does when the call goes wrong.
Testing an interactive voice response system, the phone menu. We test every path, keypad input, time-outs and routing, and the prompts callers hear.
Yes, for paths that repeat, such as menu routes, regression runs and load. Calls that need judgement, such as tone or an upset caller, stay with an engineer.
We place many calls at once and look for dropped calls, slower answers and context that leaks from one call to another.
We rerun the same call set and compare. Behaviour can change without any change to your code, so each model change is a reason to test again.
Tell us who calls and what they ask. In a complimentary call we will outline the first test set.
