What kind of testing (and from whom) would have caught this?
Usually there's a hidden config register where we can change "the number for 911", so for some portion of testing, we'll set that to "Chris's phone" and inundate a coworker with calls, but once we've been through a shakedown with that, it's time to coordinate with the local PSAP and identify a slow time when they can field some real test calls from us.
There are all sorts of safeguards here -- they want a regular phone number for one of the testers, so if the test phone malfunctions in any way (say, calls complete but audio doesn't open), they can reach us out-of-band. And it's always perfectly clear that they can cancel the activity at any time, if enough real 911 calls come in that they don't have spare operators for our testing.
It's been a long time since I was on the carrier side, but I remember doing tower turn-ups, we'd also place one test call per carrier-sector, to make sure the location info was transferred correctly. Similar coordination but it was largely a formality because it was usually just 3 or 6 calls, and very brief ones at that.
In the instant case, both the phone maker (Google) and the carrier (unsure) should've exercised this in their acceptance testing. Since it sounds like a Teams bug, it's understandable that they didn't catch it, but also unacceptable that Teams could interfere with the ability to dial 911. Since we've now learned that apps can interfere with that, this hugely balloons testing requirements until/unless they fix the OS so apps cannot interfere.
When I worked at Motorola doing mobile infrastructure, you couldn't even merge your code into a release candidate branch unless it was tested against emergency calls, for all the reasons you listed (plus more).
We used giant attenuators screwed on to the antenna plugs because everything had to be running at full power to ensure that it was as life-like as possible. Every once in a while, though, someone didn't screw the attenuator on tight enough and the emergency call would be picked up on the real mobile network and the fire department would show up in our parking lot.
There is most likely an issue but we don't really know what it is. how do you know it's not on the Verizon side?
Most likely half the 911 calls in the US are made from Android phones and we never heard of common issues.
i know it isn't a verizon problem, because google tried to blame teams.
I don't know your definition of playing it down.
he had contacted Google support, but unfortunately, he do not get response now.
It needs to be a carefully managed feature, but it's certainly not "zero need".
911/112/etc. calls should just not be screenable or blockable by apps or susceptible to third party app crashes. They should be short-circuited to just happen on the default phone app, with little possibility for any interference from apps on the system.
or where you can test it, but that testing is not sufficient to ensure the functionality works
then your design is not fit for purpose.