Considering User Experience when Testing Push Notifications in Messaging Apps

[article]

Configuration management (CM) helps us verify and validate that software and systems meet both the intended and, more importantly, the required use by our customers. The physical, technical details of CM can be quite challenging, but equally important is the user experience, which some CM analysts do not realize is a required part of their job. In CM terminology, this is called a functional configuration audit.

This article analyzes the way messenger apps behave on our beloved handheld devices. Most of us use messenger apps every day to communicate, whether in the form of text, photo, audio, or video, so heeding user experience is essential.

Consider the State of the App, Device, and OS

An app’s push notifications are facilitated by the OS of the mobile device and utilized by the app. When developers create the code for the app and its notifications, they use the built-in libraries of the specific OS to implement the features in the code. So whether they’re running on an Android, Windows, BlackBerry, or iOS device, messenger apps are designed to interface with push notifications in order to implement functionalities that keep us updated on a regular basis.

When developers code for mobile web apps and push notifications, they have to keep in mind that users on different OSes should see the same thing. The QA team must test a new or updated app across all platforms, and all possible states of the app and the device have to be factored in.

Here, I’ll analyze what to look for when the app is in the foreground or pushed to the background, and when the mobile device is in a locked, offline, or switched-off state.

When the app is in the foreground
When we are in a chat thread with someone, say, user A, and they send us another message, whether it’s on an iPhone or an Android device, we should not receive any notification. We will simply see the new message in our chat thread.

Chat thread on an Android device Chat thread on an iOS device

But, if we are in a chat thread with user A and user B sends us a message, on an Android device, we will receive both audio and visual notification. Even if we are on another screen in the same app, we will receive the alerts. However, an iOS device sends only the audio alert.

This is an example of the differences between OS libraries that the QA team has to be cognizant of when they are testing how a messaging app should function.

When the app is in the background
If the app is running in the background, the notification will ideally display the exact nature of the message received, whether it is an audio message, a photo, a video, a sticker, or simple text.

On Android devices, when we receive a message, we can see the sender's name and the message on the notification panel. If the message is long, we can see only its initial part. Until we access the message, we will see the app icon on the notification panel, and when we tap on it, we will be taken to the chat thread in the application.

The notification panel displays the name of the sender and the message received The app icon stays on the screen until the user accesses it

The notification for more than one received messages will be displayed as, for example, “2 messages from 2 conversations.” They may be from the same sender or from multiple people.

However, on an iOS device, we see the notification for a few seconds and then it disappears, so if we are not around, we might not know about the alert until we access the app. Another difference is that every message is displayed separately on an iOS device, even if they are from the same sender.

On an iOS device, we see the notification for a few seconds and then it disappears Every message is displayed separately on an iOS device

When the device is locked
If our device is in a locked state, whether it is an Android or iOS, it will still receive audio and visual notifications. On an Android device, we will not be able to see the alert until we unlock it; on an iPhone, we have the option to set the screen to on/off so that we can see the alerts on the locked screen itself as soon as we receive them.

On an iOS device, we can see the alerts on a locked screen

When the device is offline or switched off
If our device is offline or we had switched it off, we would want to be notified of message alerts as soon as we are back. We can see the notifications on the lock screen once we come online.

On an iOS device, if the same sender has sent more than one message or called us while we were offline, then only the last message or missed call notification, as the case may be, is visible on the locked screen. If more than one person have sent messages or called while we were away, then as soon as we come online, we will see only the most recent message.

On an iOS device, the last message or missed call notification from when we were offline is visible on the locked screen

On an Android device, however, the count of all the messages received will be shown as, for instance, “2 new messages from 2 conversations.”

The Importance of User Experience

Testing push notifications involves taking into account all the possible states of the app and of the device at any given time. If the app design needs work at such a granular level, just think of the testing effort required to test for all possible scenarios. It is a challenge and an opportunity for the testing team to plan their testing strategy so that no scenario is left to chance and that the app works well.

Understanding the user experience is essential for delivering quality software that will help create a loyal customer base. Make sure you understand both the physical and functional aspects of your configuration audit.

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.