Considering User Experience when Testing Push Notifications in Messaging Apps

By: Ritinder Kaur

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.

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 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.

Full article...

Other Resource

... to read more articles, visit http://sqa.fyicenter.com/art/