Our Web App is a call center app. One of the key functions of our Web App is to make VoIP call and then do post call processings. But we can't find a tool/way to do automate testing, which involves making a phone, hold/unhold, hang up, etc, i.e. the very basic phone call operations and some post call processings.

For example writing some test script to click the phone call button is not hard but how can I make sure that actually makes a phone call; how do I make sure hold/unhold button, hang up button etc actually work ?

Without test-automating these key functions the CI/CD process doesn't show much value too. The CI/CD process so far is just to show the webapp can be deployed without knowing either it can function correctly or not.

So I have 2 questions here: 1. is it possible to automate test the phone call functions 2. if not how can I make most of CI/CD ?

--- update ---

When we do manual testing we will make 2 kinds of phone calls, 1. call each other 2. toll free calls, one advantage of calling those toll free call is we can also test DTMF function as those toll free calls all have their IVR set.

  • I think we need more information. What technology is involved in the actual phone call functions? Does the web app just make use of APIs for that? Or, are you looking to automate the actual telephony/network protocol aspects? Does it need to be real functions? Or, can you make use of mocking?
    – Lee Jensen
    Commented May 17, 2022 at 15:30
  • You could consider playing 1k hz tone during the call and have some solution to capture and verify 1k hz is received. Need to research on solutions. Need analysis if roi is satisfactory
    – edm
    Commented May 18, 2022 at 0:47
  • @LeeJensen the web app calls some APIs to do phone call, for web app we don't looking to automate the actual telephony/network protocol aspects. We just want to make sure the call is actually placed. It needs to be the real function (not mocking) because this is the basic function of a call center web app. Commented May 18, 2022 at 1:34

1 Answer 1


This can be a challenging question to answer. I see a lot of people with experience in just doing UI test automation without getting involved in API testing or full-stack test automation, so there may not be a lot of answers to this question. Also, not everything can or should be tested via the UI.

First, it's going to be beneficial to understand that not everything can be tested via automation, nor should everything be tested via automation. It'll also help to understand the Agile Test Pyramid to understand the different levels on where to apply test automation.

  1. is it possible to automate test the phone call functions

I would say that this is one of those areas where it is not feasible to do test automation. What phone number are you going to call? Do you call a virtual phone (e.g. a Google Voice number) or a real landline/mobile phone? How do you verify that a call was successful? You can't have any automation that picks up a landline or mobile phone. If you use a Google Voice number, you could use Selenium to perform actions on their app, but then you're stuck on what to assert when you answer a call? How would you validate the audio is active? FYI: This might be against Google's Terms of Service, so you need to really check that this is legal with those terms and you should check with your company's legal department on this

If this occurs, then you're at the mercy of Google and they may change things you can't account for, so that means a lot of updates/maintenance on your end to keep up with Google's changes. Is that worth the time and money to do this? In my opinion, it's not worth it.

  1. if not how can I make most of CI/CD ?

Understand the differences in test automation within the tech stack and the Agile Test Pyramid. It's also good to understand the concept of "separation of concerns."

You should use test automation on the UI to validate that the UI is working. But, if you click the phone call button, the UI test automation does not need to validate the phone call has been made. You just need to validate if it calls the appropriate API function.

You need to be using automation for API tests separate from UI tests. And you need to be using mocks to verify proper responses. I can't see how to do this without mocks!

From a CI/CD perspective, you use it just like you normally would on any build or test scenario. You ensure your unit tests are run; you ensure your integrations tests run; you ensure your UI tests are run. If any test fails, the build stops and reports the error. Some tests may take longer, but that's not an issue with CI/CD systems. I think of CI/CD like a highway system: there are no inherent changes you need to make based on type of vehicle present (vehicle = test in this case), and the highway will work for all types.

For a personal example, I once tested smart TVs. (Yes, this isn't about phones but the concepts are similar.) The software you use on a smart TV is just a web app running on a localhost server (being the physical TV). For this, it was easy to run the web app on my local computer or CI/CD (a TV wasn't needed.) How do I then test that a TV remote worked on this web app? You can't use a mouse or a keyboard to navigate. The TV remote just communicated via REST APIs, so I ensured that the APIs had their own test automation. I was then able to call those APIs in my automation and mock a response for my specific test cases. When you're integrating with physical hardware or network/telephony protocols, utilizing mocks is the best way to handle test automation.

Another example, I'm working on a project now that is heavy on APIs using a micro-service architecture. We rely on dozens of 3rd party API integrations. Here, I have zero control over those 3rd parties so, in order to create test automation, I have to create mocks and simulate their API payloads to ensure my team's software work correctly.

When you test each layer separately and really get those tests in a solid state, you'll prevent bugs from bubbling up to the surface. Then, you can concentrate on integration points between those layers (have the UI call/mock the APIs or have unit tests call/mock the APIs).

Additionally, look for examples from other companies. Twilio/Zipwhip and Zendesk are all about using a web app to perform phone calls and SMS messaging. See if they have tech blogs or conference talks detailing how they solved this problem because they absolutely use test automation and mocks for this.

In further searching, Twilio uses a form of mocking they call "Magic Numbers". These can be used by their internal dev teams and any dev team wanting to integrate with them using their APIs. Magic Numbers are virtual numbers that do not correspond to any landline or mobile phone. The idea behind mocking, Magic Numbers, etc is that if your software works here, it will work with real phone numbers. This is an easier and faster approach then using real phone numbers.

Sorry for the long answer. This is a challenging problem to solve that goes beyond a typical web app implementation.

  • “Twilio/Zipwhip and Zendesk are all about using a web app to perform phone calls and SMS messaging“ That is actually one of reasons I think it maybe be done even though we have not been able to do it! Commented May 19, 2022 at 1:52
  • How can I make use of CI/CD is another concern if I can't test phone call automatically. You didn't address this (enough) I would say lol. Commented May 19, 2022 at 1:58
  • "Do you call a virtual phone (e.g. a Google Voice number) or a real landline/mobile phone? " We do 2 kinds of phone calls when doing the test. 1 call each other 2. toll free calls, one advantage of calling those toll free call is we can also test DTMF function as those toll free calls all have their IVR set. Commented May 19, 2022 at 2:32
  • @Qiulang邱朗 This is a hard question to answer in a short form community. Simply, it's not a situation where you test everything in the UI, you need to test at all stack levels, which any CI/CD can handle. These companies are heavy on API, so most of their tests are handled here. I'll update the answer with some other info.
    – Lee Jensen
    Commented May 19, 2022 at 15:57
  • Hi I suddenly remembered a question I asked at least one year ago. Care to take a look? I would like to hear your opinion there too, thanks! softwareengineering.stackexchange.com/questions/420414/… Commented May 23, 2022 at 3:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.