What to look for when testing SMS apps

Short Messaging Service, or SMS, components of an application require special attention when developing a test plan. Anything from basic sending of an SMS to user interactions and internationalization can be a source of problems and need to be tested.

Texting may be simple for the user, but not for testers. Here are some of the things that we have tested for on the SMS components of applications.

Service Provider or SMS Engine Setup

The first step in sending an SMS is to either establish a link with a service provider or create your own SMS engine. Regardless of the method you choose, you need to test that you are able to create and send your message and that your message is being sent over the right path.

 Message length

While creating the message you need to watch the message length. Early phones could receive only one message at a time and with only a limited number of characters. As technology advanced, longer, threaded messages became possible.

You don’t control the recipient’s device, so you need to test that longer messages display well on devices that don’t support longer formats or test that your messages don’t exceed the 160-character short format depending on whether you choose to limit your application to short-format messages.

If you choose messages longer than 160 characters, then you need to split the message up for short-format devices and ensure that you clearly identify which message is the first part and which are subsequent parts and, of course, test your implementation.

Reply Options

What is the purpose of sending the message? There are two common answers to this question.

The first is to inform. So a bank might let customers set up SMS notification for when a withdrawal is made. For informational messages, you just need to check that the message content is correct and it gets delivered.

The second is to solicit a response. A shop asking you to rate their service is a good example. SMS messages that require replies need to test some special scenarios.

  • All of the response options function and are correctly placed in the message content.
  • Single and multi option replies function as required.
  • Response is handled properly by the server.
  • Correct action is taken after receiving the response.
  • Invalid responses are handled properly.
  • Response can be entered either with the option text or the digit assigned to the response as required.
  • Case sensitivities of the reply options.
  • How the application handles duplicate responses.
  • How the application handles responses after expiry time.

Format and Content

The message content which is generated should be properly formatted and all the formatting issue should be tested.

  • Special characters should be properly encoded and placed.
  • Line feed characters should work correctly.
  • Line spaces, if present, should be display properly.
  • Reply options should be properly placed and should be identifiable by just reading the message.

Dynamic content

The way you generate your content completely depends on your application. Predefined scripts, sometimes in combination with a database, are commonly used to generate messages in web applications.

Regardless of how you generate the message, any dynamic content should be properly verified.

  • Dynamic content needs to be checked for accuracy. An extreme example is ensuring that the bank withdrawal message should show the balance from the correct account.
  • Dynamic content needs to be checked for length. Entering a long name, for example, shouldn’t break your message.

Opting Out

It is inevitable that some users that join your service will want to opt out of SMS notifications. Opt out mechanisms should be properly tested.

So, for an application where texting stop opts you out of the messages, check the following scenarios here.

  • If user respond with stop term, then unsubscribe his/her device to receive further messages.
  • Also unsubscribing should also make the desired changes in the database.
  • The stop message should be case insensitive.
  • A response from any device that is not registered should result in no action unless otherwise required.

Different Countries

If your application is global, your recipients will live all over the world. You need to make sure that your application works in all supported countries. When sending messages to different countries you should check the following scenarios.

  • Proper country code is added to the message address.
  • Your application complies with local regulations. Some countries restrict the amount of SMS that can be sent over a period of time to preserve bandwidth for emergencies. You need to make sure that your application stays under the limits.
  • The cost for each message depends on the country. You need to make sure that your application records the correct data in database to ensure billing is handled properly.


Reporting is important to any business application. For applications that use SMS, the status of messages can be tracked serving as the basis for delivery reports. You will want to test you are reporting the correct status. You need to simulate various scenarios and then test the reports. Some of these scenarios are:

  • Message sent successfully.
  • Message not sent due to internal failure (ie. misconfigured application).
  • Message not sent due to external failure (ie. service provider failure).
  • Message re-sent.

Check Logs

Log files help us figure out the process flow and are useful for debugging. We need thorough and detailed logs. Logs must be set properly to capture each and every detail from generating the message, initial routing of the message and delivering the message. If any debugging is necessary, you just need to reference the logs for that event and will be well on your way to discovering the source of the bug.

For logs to be a reliable debugging tool, they must be properly tested by simulating different responses. Log file documentation also needs to be prepared if it is not already present.

Generally an SMS log statement is based upon its levels.Various log levels are:

  • FATAL: This indicates that the server or application failed.
  • ERROR: This indicates that application will continue to run but specific functionality that is processed by the current thread failed.
  • WARN: This indicates that application will continue to run but specific functionality that is processed by the current thread may be operating on some data that is not appropriate.
  • INFO: This indicates progress of the specific functionality that is processed by the current thread.
  • DEBUG: This provides fine-grained information about the progress of the specific functionality.The DEBUG level is used to log messages that are useful for customers, support and development to diagnose problems remotely.

The post What to look for when testing SMS apps appeared first on OptimusQA.