One way to classify SMS apps is the following: MO Initiated and MT Initiated.
MT Initiated apps are usually app initiated – this means that the app initiates the interaction with the user. A common example of such apps are SMS “spam” where the user gets a message like “<ADV> send ‘prize’ to 76888 to win an iPad” – and the user replies with just that. Another example are say a website (or mobile site) that asks you to enter your friend’s mobile number to send them a link – the MT would look something like “Greetings, your friend howler just sent you a link – http://bit.ly/qwerty”.
MO initiated apps are those that are user initiated – this means that the user initiates the interaction with the app. One example of such an app are SMS search type apps eg. “search obama news” for all news related to President Obama.
This means that when testing MT initiated apps – you start by sending a MT and will need to simulate a MO response and see if the app receives it and processes it correctly. For MO initiated apps – you start by sending a MO to the app and wait for a correct response from the app.
Another way to broadly classify SMS apps are session-less apps and session-based ones. Now, SMS has no way to send cookies or headers like HTTP, hence for most cases they are sessionless. One way to achieve sessions for SMS is the use of shortcode extensions. Say for example the shortcode of an app is 82434. If you are able to negotiate with the operator to provide 100 extensions to this shortcode – say 8243400 to 8243499 the 00 to 99 can be used as “sessions” for that particular user. One example of this is a chat type app where each “session” corresponds to a particular friend the user is chatting with – say John maps to 01 and Mary maps to 02 depending on which person the user started chatting with. In this case, when John sends message to the user, the shortcode will then be 8243401 and the user just needs to reply to that SMS to reach John.
In the case of such “session” based apps, testing can get a little more complex as you will need to take into consideration cases for (a) extension allocation, (b) extension mapping (to “session”), (c) extension recycling ie. you may need to design test cases for each of these.
For extension allocation, you test that the extension is allocated correctly to the session – this depends on the algorithm used by the app and goes hand-in-hand with extension recycling eg. LRU, round-robin. For extension mapping, you test that the extension maps to the correct session. If the test case sequence can be designed well, you can include all 3 cases into 1 single test run.