On this page
- Key facts
- What is IVR testing, and how is it different from call testing?
- What should you test in a phone menu?
- How do you test a voice agent that answers the phone?
- How do you test a voice agent that has to get through a menu?
- How do you place the test calls?
- How RingTru fits in
- Where we have not tested yet
Call and IVR testing for voice agents
What to check when you test a phone menu or a voice agent by ringing it, from key presses and silence to voicemail, transfers and how many calls you can place.
By Greg East, 6 minute read. Sources checked .
IVR testing means ringing an automated phone menu and checking that each option, key press and transfer does what the menu promises. Call testing is the same job for any phone line. With a voice agent it also covers the open conversation that follows the greeting.
Key facts
- An IVR is an automated telephony system that works with "voice recognition and Dual-Tone Multi-Frequency (DTMF) input from a telephone keypad" (Wikipedia).
- Twilio's
<Gather>waits 5 seconds by default for input, and if none comes the call flow continues to the next instruction (Twilio docs). - Twilio grants each account one call per second by default for calls created through its API, and accounts with an approved business profile can raise that to 5 (Twilio docs).
- Twilio says its answering machine detection "will not always return the right answer" (Twilio docs).
- Vapi, Retell and ElevenLabs each have a tool that lets an agent press keypad tones to move through someone else's menu.
What is IVR testing, and how is it different from call testing?
An IVR, short for interactive voice response, is the "press 1 for sales" system. Wikipedia describes it as automated telephony that takes keypad tones, spoken answers or both. IVR testing checks that menu: every branch, every prompt and every place a call can end up.
Call testing is wider. It asks whether a number rings, who answers, whether the audio is clear and whether the call ends where it should. A menu is one thing you can call-test, and a voice agent is another. You will meet one of three set-ups, and each needs different tests.
- A classic menu that callers dial into.
- A voice agent that answers the phone in place of a menu, or in front of one.
- A voice agent that rings out and has to get through someone else's menu to reach a person or a service.
What should you test in a phone menu?
Start with the paths, then break them.
- Every branch to the end. Ring, press each option, and check you land where the prompt said you would. Include the option that nobody uses, since that is where stale routes hide.
- Silence. Twilio's docs say that when a
<Gather>reaches its timeout with no input, the call flow carries on with the next instruction. So say nothing and hear what that instruction is. A good menu repeats itself or offers a person, and a bad one hangs up. - The wrong key. Press a digit the menu does not offer. Press too early, before the prompt has finished. Press too few or too many digits where it asks for an account number, because Twilio lets you set how many digits to expect and which key ends entry,
#by default. - A way out. Press zero, say "operator" and say "I want to speak to a person". The menu should do something sensible each time.
- Spoken answers. If the menu takes speech, test accents and noisy lines the way you would for a voice agent. Our guides on UK accents on phone audio and accents and background noise cover how.
- Closed and busy. Ring out of hours, and ring a transfer destination that is engaged or does not answer. See our guide to handover and looping failures.
- Voicemail. Check what a caller hears when a transfer ends up on a voicemail greeting. Detection is not perfect. Twilio's own page gives the example of a very short greeting being taken for a person.
How do you test a voice agent that answers the phone?
The menu checks above still apply to the greeting, the first question and any keypad shortcuts you kept. After that you are testing a conversation, which a menu test cannot cover. People say things in the wrong order, change their mind and talk over the agent.
Retell's guide to phone call testing lists keypad menus, transfers and voicemail detection as things to check on a real number, and notes that a phone call also tests the carrier audio path. Our guide to test calls for a phone agent covers how many calls to place and what to check on each. For the conversation itself, see interruptions and identity checks.
How do you test a voice agent that has to get through a menu?
Outbound agents meet menus that were not built for them. The big platforms each give the agent a way to press keys. Vapi's docs describe a DTMF tool that lets the assistant enter digits on the keypad, "useful for IVR navigation or data entry". Retell has a press digit node that is "used to navigate through IVR" systems, where the agent stays silent and works out which digit to press. ElevenLabs offers a tool to play keypad tones and lists entering extensions and PIN codes among the uses.
You cannot control a third party's menu, so build a stand-in you can. Then run the agent against it with the awkward cases.
- A menu that reads its options slowly, or changes the order between calls.
- An option that sounds like another, such as "billing" and "booking".
- A prompt for an account number that ends with the hash key.
- A menu that says "this call may be recorded" before anything else.
- A menu that sends the agent to voicemail.
For each call, check the digit that was actually sent, not only what the agent said it would press. Vapi's tool sends tones out of band through the phone provider, so the call log and the provider's record are the places to look. Vapi also lets you pick who handles voicemail detection, so test with each setting you might use.
How do you place the test calls?
There are three ways, and you may want all of them.
By hand, you ring from a mobile and listen. That is the only way to hear the odd thing nobody thought to script, and it does not scale. With a script, you place calls through an API. Twilio's docs say you send a request to the Calls resource to place one, with a default that starts at one new call a second per account, so a big batch ramps up slowly. With simulated callers, a model speaks to your agent and a judge scores the call.
The same limit matters when you load-test. Twilio says calls are rate limited at the account level, so a failed batch can tell you more about your limits than about your menu. Check the limits your own provider sets before you read anything into a failed run.
How RingTru fits in
RingTru's simulated callers are built to ring a phone number and hold a conversation, and our AI judges are built to score each call against written rules. That suits the voice agent that answers the phone. Our voice agent testing guide sets out the wider approach.
Where we have not tested yet
We have not tested keypad menus ourselves, and this guide does not claim that RingTru presses keys. We have not placed test calls against any third party's IVR. The platform behaviour above comes from each vendor's docs as read on 31 October 2026, and we have not checked how any of it holds up on a live call.
These guides name vendors in plain text and are not endorsed by any of them.