IVR testing means placing a call, sending input at each menu level, and checking that what comes back is what you declared should come back. Everything else is detail about which paths you choose, how often you run them, and whether a person or a machine places the call.
This is a method, not a product page. If what you want is software that runs these tests on a schedule, IVR testing software covers that separately.
What IVR testing actually checks
Four different things, which is why “the IVR is broken” is never a useful bug report:
- Reachability. The number connects and something answers. A dead DID fails here and nothing else gets tested.
- Routing. Option 2 reaches the queue option 2 is supposed to reach. This is where most real defects live.
- Prompt content. The caller hears the words they should hear. A menu can route perfectly while announcing hours that changed in January.
- Timing. Connect time, hold time and how long before a human answers. This is what an SLA is written against.
A test that only proves the line answers has checked one of the four.
The test cases worth writing
One row per case. The point of writing them down is that “test the IVR” is not repeatable and this is.
| Test case |
Input |
Expected result |
Why it matters |
| Main menu answers |
Dial, wait |
Greeting plays within the expected seconds |
Catches dead DIDs and carrier routing failures |
| Each top-level option |
Press 1, then 2, then 3 separately |
Each lands in its stated destination |
Options shift by one when someone inserts a new item |
| Each second-level option |
Press 2, then 1 |
Correct sub-queue |
Most defects live two levels down |
| Deepest path |
Full sequence to the terminal step |
Correct endpoint |
Nobody tests this by hand |
| Path to a human |
Zero-out or “speak to an agent” |
Reaches a queue or ringing agent |
The path callers use when everything else failed them |
| Prompt wording |
Listen at each level |
Prompt contains the expected phrase |
Routing and prompt correctness are separate failures |
| Invalid input |
Press a key not on the menu |
Graceful re-prompt, no disconnect |
Routinely broken by menu edits |
| No input |
Press nothing, wait out the timeout |
Re-prompt, then defined fallback |
Same |
| Timeout and retry |
Wait past the interval twice |
Waits the stated interval, does not drop after one miss |
Silent regression after a platform upgrade |
| After-hours tree |
Run outside business hours |
Closed message and correct fallback |
A whole second IVR nobody tests |
| Holiday routing |
Run on a configured holiday |
Holiday message |
Stays on past the holiday more often than you would think |
| Each DID and region |
Same tree, different inbound numbers |
Identical behaviour |
The same IVR through a different carrier can behave differently |
| Speech input |
Speak the menu keyword |
Same destination as the keypad equivalent |
Hybrid menus have two input paths and one gets tested |
| Transfer to voicemail |
Follow the voicemail path |
Recording starts |
Fails quietly and nobody notices for weeks |
Fourteen cases for a four-option menu with one sub-level. That number is the argument for automating: four options with four sub-options each is sixteen paths before you have tested a single unhappy one.
Types of IVR testing, and which you actually need
Functional testing confirms each path does what it should. This is the table above and it is where most defects are found.
Regression testing re-runs those cases after a change. IVR defects are overwhelmingly caused by edits rather than infrastructure, so this is the highest-value kind and the one most often skipped.
Performance and load testing asks what happens under concurrent call volume. It is a separate discipline needing a separate tool, and it answers a question functional testing cannot.
Usability testing asks whether the menu makes sense to a human. A person has to do this. It cannot be automated and it does not need to run continuously.
Integration testing confirms the IVR still talks to the ACD, CRM or database lookup behind it. Worth running when either side changes.
Security testing looks for paths that expose data, especially where an IVR takes card numbers or account details through DTMF.
Most teams need functional and regression coverage running continuously, usability once per redesign, and load testing only before a known peak.
The four failures that account for most incidents
Every one of these looks healthy from inside your network, which is why internal monitoring does not catch them.
The DID stopped terminating. Your SIP trunk is registered, your PBX is fine, and calls to one number go nowhere because the carrier stopped routing it.
Someone edited the call flow. A new option was inserted into the main menu and every option after it shifted by one. The IVR is perfectly healthy and sending everyone to the wrong department.
The recording is stale. Routing is correct and the greeting announces opening hours that changed two quarters ago.
The after-hours tree never switched back. A holiday schedule stayed on past the holiday. Callers hear the closed message on a Tuesday and nobody internally notices, because nobody calls their own main number.
Manual testing, and where it stops working
Manual testing is the right tool for usability, for exploratory work on a new call flow, and for judging whether a prompt sounds right. Keep doing it for those.
It stops working for coverage. A person dialling a menu tree proves the IVR worked at 2pm on a Tuesday from one phone on one carrier. It does not scale past a handful of paths, it never covers the after-hours tree without someone working after hours, and it is skipped exactly when it matters: thorough on release day, skipped on the small change three weeks later that breaks option 3.
It also leaves no evidence. “I called it and it was fine” is not something you can put in front of an auditor or a customer disputing an SLA.
Automation replaces the repetition and the hours, not the judgement. Deciding what is worth testing is still a human job.
How an automated test call works
The mechanics are worth understanding before you evaluate tools, because they explain what any of them can and cannot catch.
A test is a sequence of steps. Each step sends something and declares what should come back: wait for prompt, send digit 2, wait, send digit 1, listen for an expected response. Input is either DTMF keypad tones or recorded audio for speech-driven menus, so a hybrid menu is one test rather than two.
The call is placed over the carrier network as an ordinary inbound call. That matters more than it sounds: because the call arrives from outside, it covers the whole path a customer takes, including the carrier leg where dead DIDs and porting errors live. Infrastructure-side monitoring cannot see those by design.
Results are recorded per step, so a failure reads “option 3 stopped routing at 04:12” rather than “the IVR is down”. Good implementations keep an audio recording, which is what settles arguments about whether a line was actually broken.
A checklist you can run
Against your own call flow, in order:
- List every path a caller can take. Not every option, every path to a terminal step.
- Mark which paths are revenue-critical and which are merely present.
- Write one case per path, with the input and the expected result at each step.
- Add the four unhappy cases: invalid input, no input, timeout, and the path to a human.
- Add the after-hours and holiday variants of the critical paths.
- Repeat the critical paths for every inbound number and region, not just the main one.
- Decide a cadence per case. Critical paths often; deep walks less often.
- Define what happens on failure: how many retries before anyone is told, who is told, and in what order.
- Re-run the whole set after every call-flow change, not just major releases.
- Keep the results. The history is the artefact an auditor or an unhappy customer asks for.
Common questions
How often should an IVR be tested? Critical paths continuously, deep menu walks daily or weekly, the full regression set after every change. Testing everything at the highest frequency is how monitoring bills get out of hand and how alerts get muted.
What is the difference between IVR testing and IVR monitoring? Cadence and target. Testing is usually a one-off before a change ships. IVR monitoring runs the same checks on a schedule against production, indefinitely. Testing says the change was safe; monitoring says the system still works three months later when a carrier reroutes your number.
Can automated testing handle speech menus? Yes, by playing recorded audio as input rather than sending tones, and by using voice recognition to assert that the prompt contains the words it should.
Do we need access to our phone system? No. Tests arrive as ordinary inbound calls, so anything reachable on a phone number can be tested without agents, SDKs or access to the PBX.
Where to go next
If you are choosing a tool, the nine-vendor landscape covers who publishes pricing and what each is built for.
If you want to run the cases above on a schedule rather than by hand, that is what the software does, and automated IVR testing covers the regression side specifically.
