“Mr. Watson—come here—I want to see you.”
When Alexander Graham Bell spoke these first words into a telephone to his assistant in the next room, he was testing a device that would lay the foundation for long-distance spoken communication in real time—something that quickly became a necessity.
Since then, computer hardware, software, and network systems have been incorporated, greatly changing this communication method. The role of quality assurance in the field of telecommunication is more important than ever, considering the need for faster and smoother communication channels.
My team recently worked on testing a telephone device that has a touchscreen in addition to the push-button dial pad, VoIP capabilities, and cloud backup. You may be thinking, how complex can it be to test a telephone? But the scenarios associated with each component are wide-ranging, considering that telephony involves not only the hardware and software, but also connectivity issues.
The testing was along the lines of black-box testing because it was a “closed” device—the software came preloaded. A closed device does not offer much ability to add software, alter the configuration, or view the debug logs. This is to prevent any inadvertent changes to the feature set that could shift focus from the intended functionality. Essentially, there are not many components the QA team can control, and consequently, there is a very limited scope for test automation. The team’s focus for this project was on user acceptance testing.
Because telephone devices now have crossed over to the realm of the interactive, this amalgamation offers some interesting challenges from a testing perspective. Let’s see what some of these could be and explore some techniques to use when testing modern telephones.
Testing a Splitter
Using a splitter helps provide multiple access points to the telephone line in different parts of the unit. The splitter divides the electrical signal into digital (for Internet connectivity) and analog (for the telephone line) so that there is no mutual disturbance.
For this project, an RJ11 splitter was used on top of an ADSL splitter—this way, the team had four devices hooked up for testing. But a word of caution here: Because the incoming electrical pulse is distributed over the wires, the more splitters you have, the weaker this pulse gets. The call quality might be impacted, or worse, the call ring might not even be audible.
Tests for parallel lines can be quite simple, such as for incoming calls. Once the call is picked up, the dial tone should cease to be audible on all other lines. Also, if multiple parallel lines are picked up in response to an incoming call, and then all but one hang up, the call should not be dropped.
When you add voicemail and an answering machine to the mix, the scope of test cases expands considerably. If voicemail is enabled on multiple parallel devices, we need to test on which device the voicemail message will be recorded. The answering machine also might be enabled on multiple devices. If so, which one should respond to a missed call?
Let’s look at another scenario. Say one device is configured for the call to switch to the answering machine after two rings, and another device is set up so that the call switches to the answering machine after four rings. On which device should the message be recorded? (Spoiler alert: It should be on the device that switches over to the answering machine earlier, after two rings.)
If more than one parallel device is configured to switch over to the answering machine after the same number of rings, on which device will the caller’s message be recorded now?
If the device is supposed to switch over to the answering machine after two rings, but at that very moment, the person being called picks up the phone, is the answering machine active now, or the call? We determined that if the answering machine stays active, it will cut the call after a certain time (it is configured as such), and the user literally will be left holding the handset! So, the call should be active and the answering machine should switch off.
This is not a comprehensive list of things to test, but it’s a good representation of the kinds of things you need to think about. Some of these questions have documented, industry-standard solutions, and some will require your team to brainstorm.
Testing for Cloud Backup Using REST APIs
When the user saves any data—say, a contact—to their telephone, it is also backed up in their cloud account via web services. To test this, it helped to study the architecture of the web services involved, considering there were multiple web service APIs. Data had to be not only updated to the cloud, but also would need to be retrieved when asked for by the user.
What should happen if there is no internet connectivity? The web service API will create a data queue to be synced to the cloud later, when the device comes online. We tested if separate queues would be generated for, say, contacts versus the call log.
Tests can be written for the data queue, too. For instance, there is a limit to the entries that a queue can store. By exceeding this limit, the team tested for how this excess data would be handled by the web service APIs. Either the earliest entries should be deleted, or the latest entries should not be added to the queue at all.
As a tester, challenge yourself to think beyond the obvious. Once the device comes online and the user saves a new contact, test whether this contact will be backed up earlier than the one in the queue.
Testing the Voicemail and Answering Machine
Sometimes, testing involves something as simplistic as using the process of elimination to find a resolution. Here’s a case in point.
The team was testing the voicemail and answering machine capabilities. To play a message recorded on the built-in answering machine of my telephone device, you tap the Play icon, (remember that the phone had an interactive UI), but there was no audio. The team started with the most probable cause: maybe there was a problem with playing the message. We tested the speaker, and it was working. The next probable cause was that there might be a problem with recording the message, because the audio channels for the handset, headset, and speakerphone were different. We determined that the message was being recorded, but because it was still not audible, it seemed from the process of elimination that it was a software issue.
While testing for call log notifications, the team made a couple of interesting observations. First, a missed call and the voice message for it were displayed together in the call log, but they should be independent of each other. If either of these is deleted from the call log, the other should still be visible. Then, while testing for call notifications, the team noticed that even when the message had been deleted, the voice message icon persisted, along with the missed call notification. It was a small detail that could easily have been overlooked and carried over to the next build.
It’s vital to have a keen eye for details like these. Keeping the turnaround time short also helps save on resources in the long run.
Testing a VoIP Application
With teams spread across continents, VoIP (voice over internet protocol) is a viable solution for real-time communication. Voice streams use special media delivery protocols that encode and transmit the audio, allowing people to communicate over the internet rather than a circuit-switched telephone network.
To set up a VoIP test, you will have to acquire a phone number that is local to the time zone where you’re testing. Download a VoIP application on your phone or computer and create an account there. When the user places a call via the VoIP application, the digital signal is transmitted to the public switched telephone network (PSTN) in the remote time zone, where it is converted into analog and then processed as a local call.
In the case of my project, the management was thoughtful enough to provide a preloaded application for enabling VoIP so that we could test for connectivity. The test team also should test for other VoIP service providers for that time zone to ensure comprehensive test coverage.
Testing Emergency Calls
Emergency numbers, such as 911 in the US, should also be tested for connectivity and call quality. It is advisable to obtain prior permission from the local authorities before calling an emergency number so that operators know it is not a real emergency and you don’t waste their time or tie up the phone lines.
Once I had set up a test time with the emergency call operators, I verified with them that the phone number and address of where I was calling from was visible and correct in their caller ID.
Be Creative with Your Testing
I think exploratory testing is vital in every project, but in a scenario such as this one, it’s particularly important to test for user journeys that are unmapped and uncharted, however implausible they may seem. There were a couple of instances in this telephone project where the unit tests were working fine, but when exploratory tests were run, the device didn’t quite function as well as the unit test results had indicated it would.
I also think it helps to list test cases in a shared sheet that anyone on the team can edit and then update issue statuses there, without having to resort to integrations. In projects such as these, where there is little scope of test automation, being able to automatically update issue statuses after every regression is a great timesaver.
Telephones look very different today from when they were first invented, and their many capabilities and components make for some interesting test cases. Don’t be intimidated! Be creative in your test techniques, be observant in looking for unexpected results, and be bold when asking questions, and you should be able to ensure comprehensive test coverage.
