Cross-platform testing for SMS functionality. Really?

Testers know the importance of cross-platform testing. Whether it be a web page or an app, testing the product on as many platform combinations as possible is very important.

Imagine that your product is a web-based SaaS. Your clients can access your product using a variety of device/browser combinations.

Thankfully, there are many solutions for testing such scenarios.

But should someone be considering cross-platform testing for a feature of the GSM protocol that rolled out in 1993?

Imagine a device with a GSM module. This device has a feature to receive SMS commands and change/report its configuration accordingly. The developer implements this feature and conducts tests with his phone. First with the supported SMS contents, then with some unsupported SMS contents. For the supported SMS content, the device changes/shares its configuration and sends a confirmation. For the unsupported SMS content, the device sends a wrong command response. All seems to work as expected for the developer and the feature is sent to the tester, me.

I also conduct tests with my phone. First with the supported SMS contents, then with some unsupported SMS contents. But for me, every SMS remains unanswered. The feature clearly says that a response will be sent by the device: Whether a config change confirmation or a wrong command response.

So I decided to pinpoint the issue by creating more test combinations. But for a feature as established as SMS, what combinations can there be? Maybe it's the GSM operator? So I source a SIM card from each of the operators available in my country (three in total) and conduct the tests again using these SIM cards on the device. The problem persists.

What else is there? Again, since this feature uses a long-established infrastructure, there aren't many options. Maybe it's the sender's device? So I source a dumb phone. Luckily, I have a Nokia 1110 lying around and send the supported/unsupported commands from this phone. The results are as expected.

So the issue seems to be the sender device, but why? I get in touch with the developer to figure out his phone details. Turns out that the developer has an Android phone and I have an iPhone. It seems that the SMS sending works differently on iPhones compared to other phones.

After the tester shares his findings with the developer, they figure out that an SMS sent from an iPhone is indeed different from an SMS sent from any other phone. An SMS sent from an iPhone always contains 4 special characters: ¥¤££

Since this feature only works for commands that the device specifically supports, the developer created a filter that only accepts printable ASCII characters to get around this issue. After this fix, supported and unsupported commands worked on my side and I sent this feature to release.

After searching, I couldn't find the reason for these 4 extra characters in every SMS sent by an iPhone. I guess that it's related to Apple's iMessage service. After the message with these 4 extra characters is received by an iPhone, the receiver iPhone switches the conversation to Apple's proprietary iMessage protocol. My main goal for sharing this story isn't about the underlying reason for these extra characters, it's to provide a guide for anyone encountering this exact issue.

Long story short, maybe cross-platform testing shouldn't be ruled out for features. Even if that feature is as long-established as SMS.

Special thanks to Ali Cenk Tüfenk for his help in recreating this issue.