Testing SMS texting applications: Key steps and considerations

A software testing expert describes approaches to testing SMS texting applications. She looks at how SMS testing changes perceptions of everyday texting, and explains key steps in the SMS testing process.

Karen Johnson
Karen Johnson

I'd been texting for a couple of years before I found myself in a position where I needed to test Short Message Service (SMS) texting. Texting, it's simple. I send text messages nearly every day as a fast way to communicate without the hassle of calling someone. Texting lets me skip phone tag. Texting, unlike email, keeps communication short and to the point. It lives up to its name, short message service.

Texting may be simple and messages themselves may be short; but it's also a service that needs to be tested, because even short text messages represent your application to your users. In this tip, I'll discuss the steps I took in planning and performing SMS texting testing.

Texting had become something I did daily, but it hadn't been something I'd tested. I had to stop and look at the process and consider where potential issues might occur and think about texting from a testing perspective. As is often the case with testing, I found my questions created a testing path. What is there to test with SMS texting?

The first step was considering with whom I was texting? With personal texting, all the contacts I was texting were friends and family, people that were already loaded in the address book on my phone. With sending and receiving messages from friends, the two way communication was pretty easy, since most of my texting was about using "reply" to a message already received. Setting up a user to receive messages from an application was the first step in the process to test. Already, this is where your experience and testing perspective may vary from the testing I faced. The fundamental consideration, however, may be the same: How do you establish the connection between your application and the user and their physical device?

In my testing context, users could opt in to receive SMS messages through a few data entry fields in the application and then receive a confirmation message on their physical device. Google Sync begins with a similar process; you enter a phone number through a browser on a PC to establish communication between the application and your physical device. A confirmation message from your phone begins the process.

From a test perspective, challenging data entry fields are often familiar territory; trying valid and invalid values, as well as partial entries and entries of incorrect values such as alpha characters in numeric fields, all the while checking for error handling. But receiving messages is only one part of the communication; can the user send messages back to the application? Is the SMS communication one-way or is it a two way exchange?

Let's look at the second part of the communication process, sending messages. In my testing context, no messages are received by the application with the exception of the ability for the user to send a message to stop or suspend the service. Suspend and resume actions are pretty straightforward testing. Once a user is in suspend status, setting the user up to be eligible to receive messages and then checking that no messages are actually received. Once a user has resumed messaging, checking that messages are received. Suspend and resume is like a light switch that can be turned on and off.

SMS test condition

But even with what should be straightforward, other questions come to mind and these questions lead to test conditions, such as:

  • Can the user send other messages -- than suspend and resume -- to the application?
  • What does the application do with those messages?
  • When a user resumes service, do they receive messages that were held while their status was suspended?

As is often the case in testing, it isn't along the straightforward or happy path testing route where issues are often found. Defects are often found where combinations of conditions come into play, here's one to consider: A user has suspended service, and no messages are received. If the user account becomes inactive, would the user be able to resume messaging? Should they be able to? Would the user need to be activated before messaging resumes or the user's resume message is accepted?

This is where testing becomes fun, exhaustive and requires a curious mentality. Can you think of those conditions? Can you find those conditions that come together in such a way that cause an issue? Every application has its own "story," its own set of conditions to puzzle through in a quest to find defects in order to improve the product the best we can in a timeframe that is reasonable and feasible.

I stopped thinking of texting as a simple personal communication tool and started looking for ways to merge my personal testing experience with my background in testing. I built a test heuristic for texting: RSTLLLL. If a heuristic sounds complicated, consider this short definition: a heuristic is a general formulation that serves to guide investigation. Testing is certainly an investigation. This heuristic is like a checklist, its non-application specific and designed to provoke test ideas. Now in addition to my personal experience and my test experience, I have a reusable tool to test SMS texting. Let's step through each of these and see what testing ideas come to mind as you consider the application and context that you're working with.

  • Reply: Can I send a reply to the sender? Does the sender receive my message?
  • Sender: Who is the sender? Does the sender's information appear correctly? If the sender is already loaded into your address book, the sender's name might appear "resolved." When the sender is a person, it would be the person's name as stored in your address book. Does your application have a name? How does the sender information appear on a phone?
  • Timestamp:What time is the message stamped? Whose time is used? Is it the time the application sends the message or is it the timestamp from when the telecom company sends the messages out?
  • List: Was the text sent to one user or was the message sent as part of a list? Were there supposed to be multiple people who received the message, did everyone on the list get the message?
  • Links: Does the message include a link? Does the link work?
  • Language: What language was the text sent in? What about Unicode characters? What about non-Latin characters?

    Length: Messages end at 160 characters. Did I receive the entire message? What if a link was included as part of the message and the link was included at the end of the message, did the link get truncated?

I haven't talked about the vast array of physical devices or how an individual telecom company could introduce other issues with the sending or receiving of text messages. Your application may introduce more variables to consider than what is outlined here.

Related content:
Software Testing: New software testing technologies bring new challenges
The first issue covers two new technology areas - virtualization and rich Internet applications (RIAs) - that are changing software testing approaches and presenting new challenges.

Texting may be simple and messages themselves may be short, but it's also a service that needs to be tested because even short text messages represent your application to your users.

Karen N. Johnson is an independent software test consultant. She views software testing as an intellectual challenge and believes in the context-driven school of testing. She has 14 years' experience in software testing and software test management. She is a frequent speaker at software testing conferences and is an active participant in several software testing workshops. She's published articles in software testing publications as well. For more information about Karen, visit http://www.karennjohnson.com.

Dig Deeper on Topics Archive