Mocking IVR system

Question

I am new to automation testing and was looking for guidance on how I can mock or create a simulator for a IVR ( automated call system ).

We have an application, which sends some user data to a third party software. This third party makes a call on our behalf to user and asks a few question. Then it sends details about the response from the user in a CSV file in a shared sftp location.

To test our system, I was looking to bypass this third party completely and create a fake system but I am not sure how one can fake a call.

Presently how we manually test is we create an user, send our own phone number so that we can get a call and answer them according to the test cases. Based on our test case we see whether we got the expected result back in csv.

Does any one has any better way of doing this and save time in manual process.

Its complicated, and I might not have explained it properly. So if you have any questions, I will try to explain it in more detail.

Answer 1

Parth,

You have a few options here.

Given that your system sends data to the third party system, you either know the format or can get the format of the data to send from your programming team. You know the format of the data returned. This is enough to build a simple simulator that will generate dummy data in the appropriate format given the input. Ideally, your simulator would read question and answer data from a config file (for ease of manipulation) and pick the question/answer data to return based on the input phone number.

This is how I'd approach the problem: given user phone number 111-111-1111, read the config data for that phone number and use the question/answer in the config file to build a CSV file in the expected format, then save it to the expected location (this should also be governed by a config file so you aren't cluttering up the real file dump). Your automation creates a user and sends the user data, then waits until the file exists in the expected location (or alternately, creates a lot of requests before starting to check result files), reads the file and compares the data against a pre-defined baseline. This method is probably the simplest to implement, although it does require some programming.

Other options you can consider:

• If your responses to the phone call are touch-tone, you may be able to simulate receiving a phone call with a VOIP application and send data that way. I'd consider this unnecessarily complex and too fragile because you would need to automate the VOIP application as well as the sending of touch-tone data.
• Similarly, using pre-recorded voice data and a VOIP application introduces needless complexity.

If you can't build or have the programming team build you a simple simulator, you can still test your application processing this way:

• Automate the application user creation and capture the user send output. You can either have the developers build a hook into the system that allows you to optionally save the data to file in the same format it would be sent or log that data when it is sent (the former is preferable, since you would not be making requests to the third party system). Regardless, you would want to use phone numbers that don't actually exist to do this. If you can't get the hook, run your tests on a system that can't connect to the third party application and build a listener to the port to capture the data. Once you have the data in the format it's being sent as, you can validate against a baseline.
• If your application processes the output CSV files, provide it with known CSV files to process and validate the application output after processing in a separate automation run.

I've used both simulation and output capture followed by input processing in automation before. It can be challenging to implement initially, but it still beats trying to automate against a third party system that you can't control.

Answer 2

The first question I would ask myself if I were you: do I have to test how third-party application works (e.g. Does the set of answers lead to an expected data in a csv file?) or do I assume that third-party app works fine and I just need to test integration between my application and third-party (e.g. Is a new csv file added to a shared sftp location gets processed by application?)

The way you test your app now does not really trust that third-party works as expected, since you have to wait for the call and answer questions asked by this app. Indirectly, you test the third-party app itself, which may or may not be your intention (is it?)

If you test integration only, you may create a fake class that adheres to the interface of your third-party app. This fake class would, for example, create a csv file with expected data after you send user data to the app and store it in an appropriate location. Afterwards, you would verify that file gets processed accordingly or whatever other actions are expected as part of integration.

Note that when you test integration with a fake class, you may still want to perform a full end-to-end test the way you do it now, but do it less frequently. Thus you gain more confidence that things work as expected for end users. For example, this third-party may change a format of response file, which would break integration with your app, but you would not find this out by using a fake class.

One more thing to add concerns test users. You mentioned that you create that every time. You may consider having a pool of test accounts that you reuse over time.