Phase 5 · 5.1
Test Strategy
Taking a Voice AI Agent live because "we spoke to it a few times and it looked fine" is not an acceptable risk at enterprise scale. A test strategy is a framework that defines, before go live, which scenarios were tested, against which thresholds and how many times. It is a planned scope rather than random trial.
It should be thought of in three layers, each with its own test type and its own definition of a pass:
| Layer | What is tested | Example measure |
|---|---|---|
| Functional accuracy | Does it give the right information, does it call the right tool | Correct tool call rate across a defined scenario set |
| Conversation quality | Is the tone right, is there needless repetition, does it flow naturally | Human reviewer scoring on a sample |
| Safety boundaries | Does it stray into subjects beyond its authority, does it protect sensitive data | Number of boundary violations, target zero |
The three layers are tested by different methods. Functional accuracy can largely be automated: hundreds of scenarios can be run quickly and consistently, and correct tool routing is measured here too. Conversation quality can be partly automated but needs human review where nuance is involved. Safety boundaries should be tested from two directions: automated tests built on known trap questions, and deliberate attempts to break the system, which is adversarial testing. Tests that only behave like a normal user will not catch misuse scenarios.
There is no fixed answer to how much testing is enough. The right measure is covering the distribution you will actually meet in production: the standard scenarios that come up often, the less frequent but realistic edge cases, and deliberate misuse. A test set focused only on the first group will be caught unprepared in production.
A common mistake: building the test set largely around the happy path. Scenarios where the customer speaks clearly, the right information comes back first time and nothing goes wrong are the easiest to test, which is why they tend to dominate. But failure in production almost never happens on the happy path. It happens in misunderstanding, in an error returned by a system, in a question that pushes at the boundary of authority. A healthy test set covers those deviations far more than the happy path.
The decision to go live should not be an automatic consequence of the tests. It has to be clear who decides that the thresholds have been met, otherwise you end up with test results in hand and no clarity about who made the call.
Automated evaluation does not replace human review, but it makes that review far more targeted. People can focus on the scenarios that pass automated testing yet need nuance, such as tone and empathy. CBOT's test system is built to run every prompt change automatically against a wide scenario set.