Why Every Campaign Needs a Functional Test

Every MYLO campaign needs a functional test because a valid configuration does not prove the customer’s real call path. Before full launch, use a small, representative, approved test record to exercise the selected connection order, provider trunk, caller ID, answer detection, second leg or IVR, two-way audio, event history, recording choice, pacing, and final result. The test is a release gate: the responsible person reviews the evidence and approves the campaign to start.

A Preview and a Functional Test Answer Different Questions

A configuration preview answers, “Is this the campaign we intend to create?” It should show the flow type, audience, lead count, agent or IVR destination, authorised caller-ID policy, pacing, recording decision, and retry policy. Approval confirms the business intent. It does not prove that the external telephone network will carry the call as expected.

A functional test answers, “Does the approved journey work in the real environment?” It exercises provider routing, Asterisk behaviour, endpoints, network and media, current agent availability, prompts, DTMF, events, and storage. Both are required. Testing an unapproved design proves the wrong thing; approving an untested design leaves operational assumptions unresolved.

Choose a Representative Test Record

Use a number owned or expressly authorised for testing. The record should match the normal cleaned format and contain only the fields required for the chosen flow. Do not select an unsuspecting customer, an employee’s personal number without permission, or a production lead merely because it is convenient.

Where the campaign uses human agents, include the real supported agent destination and verify that the person is ready. Where the campaign uses an IVR, use the approved audio and result mapping. If campaign behaviour varies by time, caller-ID pool, agent group, or number format, choose enough controlled cases to cover those material variations without turning the test into a full launch.

Test the Selected Call-Leg Order

In customer-first flows, confirm that the customer test leg originates, the answer is detected, the correct agent mobile or extension is called, and the legs bridge. Note what the test customer hears while MYLO seeks the agent. In agent-first flows, confirm the agent answers and is ready before the customer leg begins. If the agent leg fails, the customer must not be called.

For customer-to-IVR, confirm that no human agent is reserved, the correct prompt plays, every approved key is recognised, no input and invalid input follow defined routes, and the final response is stored accurately. Test an incomplete call as well as a completed response.

Confirm Identity, Audio, Events, and Recording

Verify that the external phone displays only a provider-authorised caller ID selected under the approved policy. Speak and listen in both directions before and after bridging or transfer. Ringing alone is not proof of usable media. Continue long enough to detect delayed audio or a fixed-interval disconnect.

Compare the audible journey with the campaign event history. The order should show which leg started, rang, answered, connected, and ended. Check that the final result reflects the real leg outcome. If recording was approved, verify the notice or consent process, that authorised audio is captured, and that access and retention controls work. If recording was not approved, confirm that no recording was created.

Exercise Failure Conditions Deliberately

A test plan should include at least one safe failure case relevant to the flow: agent unavailable, customer no answer, invalid IVR digit, or provider rejection on a controlled destination. Confirm that customer no-answer retry remains disabled by default or that only one eligible retry follows the explicitly approved setting. Confirm that an agent-side failure never consumes a customer retry.

Pause and resume should preserve state and avoid duplicate calls. If restart recovery is material to release readiness, interrupt only in a controlled non-customer test environment and verify that the campaign recovers paused, reconciles state, and requires human approval before resume.

Turn the Result Into an Approval Gate

Record the campaign version, test time, test number owner, provider path, expected events, observed events, caller ID, audio result, recording result, and any discrepancy. Assign each defect to an owner and rerun the exact failed case after correction. “It worked later” is weaker than a traceable retest of the original scenario.

The campaign owner approves full start only after required cases pass and the operating team is ready. Re-test after material changes to flow, trunk, caller ID, prompts, endpoints, agent groups, network, recording, or runtime code. A functional test is not a one-time ceremony; it is evidence tied to a specific release state.

Build a Small Test Matrix

A one-row happy-path test may be sufficient for a simple release, but material variations need explicit cases. List the supported flow, first-leg result, second-leg or IVR result, expected event sequence, caller ID, recording expectation, and final campaign status. Keep the matrix proportional: it should cover meaningful risk without becoming uncontrolled production calling.

For a multi-agent campaign, test at least one representative endpoint type and confirm that unavailable agents are not treated as capacity. For a caller-ID pool, verify only authorised numbers can be selected and inspect round-robin behaviour with controlled calls where required. For one eligible no-answer retry, use an authorised test number and confirm the attempt counter does not exceed the approved boundary.

Include privacy and operational checks in the result. Confirm that only authorised roles can view the lead and recording, that a paused test starts no new work, and that reports distinguish leg outcomes. If the campaign uses voicemail detection, external forwarding, or another environment-dependent feature, test it through the actual provider path.

Sign-off should name the campaign version and evidence reviewed. A later edit to a prompt, route, agent group, caller-ID source, or runtime policy invalidates the affected cases and requires focused regression testing before the edited campaign launches.

Test From the Customer’s Perspective

Have a tester who did not configure the campaign listen to the full call. Confirm that the business identity is clear, the opening is not misleading, waiting time is acceptable, audio volume is usable, and the next action is understandable. A technically correct event sequence can still produce a confusing or disrespectful interaction.

Record qualitative observations separately from pass-or-fail technical evidence. The business owner can improve wording and timing without obscuring whether signalling, media, and state transitions passed. Both kinds of evidence matter before a customer-facing launch.

Functional Test Checklist

• Approve the preview before testing the real path.
• Use expressly authorised representative test numbers.
• Exercise the selected call-leg order and failure handling.
• Verify authorised caller ID, answer detection, and two-way audio.
• Compare audible behaviour with leg-aware events and final results.
• Check the explicit recording choice and access controls.
• Rerun every failed case and obtain approval before full start.

Creation Approval and Start Approval Are Separate

Approving the campaign proposal permits creation of the persisted campaign; it does not authorise production dialling. A representative functional test must first exercise the selected connection flow, destinations, caller ID, audio, events and recording choice. The responsible user gives a separate Start approval only after the test proves readiness.