SMS actions

kapptivate Testing & Monitoring supports two SMS actions:

 

The Send SMS action is located just below the USSD Command in the action menu:

 

Once selected, the form looks like so:

 

The form in itself is simple, there is an input field to enter the SMS recipient's phone number (with a country code selector tool on the left), a field to type the SMS message, and an option to wait until the reception of the delivery report sent by the SMSC (Short Message Service Center).

The form for the Send SMS action in tests is very similar:

 

There are some differences though:

The following specific assertions are available:

 

The Wait SMS action is quite a special case, because it is not present in the usual action menu. Instead, you can send a Wait SMS action by clicking the blue button with the mailbox icons that is present in the Send SMS action:

 

And also in the USSD Command:

 

Once you click it, you will receive all the past SMS received by the SIM currently in use, along with information such as their sender and the time and date of their reception:

 

You can create a new Wait SMS action from zero, in a test. Or you can first get a SIM's SMS from the Remote access page, then go to the Manual testing's History page and create the Wait SMS from the SMS previously received by clicking the Add button on any of them:

 

Then, click the Create test button. It will create a test with one Wait SMS action for each SMS that you previously Add-ed:

It's an useful shortcut, because it will automatically fill the Wait SMS action's details such as the Expected Message (area 1) from the selected SMS. And even more useful is the assertion on the Sender (area 2). Because Sender assertions in Wait SMS actions have a special behavior in tests.

 

When a test contains a Wait SMS action with an assertion of the Sender, this assertion will not only be used to verify the sender after the action is completed. It will be used to check SMS as they come in, and reject SMS whose sender doesn't match the expected sender. For instance, if you assert that the sender must be kapptivate inc., and the SMS received is from another sender, the SMS will not match. If no other SMS with the right sender (and expected message) comes, the action fails.

The remaining assertions are always played on one SMS only, the first SMS that matched the criteria (it had the right message and sender), as in the example below:

The assertions are played on the matching SMS (the first SMS) and not on the remaining, additional SMS.

 

When running a Wait SMS action in manual testing, you will get all the past SMS. However, the behavior is different during a test. In a test, a Wait SMS action can only wait for new SMS (not past SMS). Or it can alternatively check SMS received since a previous step. But there is no way that it can get all past SMS, even SMS from a time before the beginning of the test.

This behavior makes sense, because when you want to check SMS in a test, you usually want to check the SMS relative to that test. But what if you could see all past SMS? You may get SMS sent in another, previous test. So the only way to make sure to have reproducible and deterministic results is to check SMS received at earliest at the beginning of the test.

 

You may want to store the content of a SMS in a variable, for later use. For instance, let's say that you're expecting a SMS telling you that you have won some money in the lottery, but you don't know how much in advance. You may want to save the amount of money won, so that you can use it in a later action. You can do so with dynamic variables (also available for USSD actions):

In Wait SMS action's Expected Message (and USSD Command and Wait USSD Push as well), if you type something in the form {VARIABLE_1-VARIABLE_2}, it means that you want to match some text with the content of VARIABLE_1 (it could be a regular expression or just hardcoded text), and save the matched text in VARIABLE_2. If the text received in the SMS doesn't match VARIABLE_1, the action fails.

The variable used to store the matched text can be a new variable, or an existing variable. Either way, it will only survive until the end of the test.

In our example above, we want to match text that contains digits, and optionally a period followed by other digits (a number, basically) with the regular expression \d+(..\d+)?. Here is what the result looks like, if the test runs successfully:

 

There are two things that you can notice:

Last, you may have noticed the button labeled Update in the result example below. This button is a nice shortcut that allows you to change at once the Expected Message everywhere, that is, not only in the current test but in all tests that contain the same expected message:

 

However, be careful, as this is not only the Expected Message of Wait SMS actions that will be changed, but also the Expected Message of USSD actions. Fortunately, the form that shows up when you click Update lets you select / deselect in which tests you want to change the expected message: