Mocking IVR system
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.
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.