A push notification is a short message that appears as a pop-up on your desktop browser, mobile home screen, or in your device notification centre from a mobile app. In this talk, @saifsms91 helps you understand what a push notification is, its types, use cases and scenarios.
We’ll use this Club thread to share resources mentioned during the session and answer any questions we don’t get to during the live session.
Hi @saifsms91 I have a few more practical questions about testing push notifications. You just started getting to the interesting bits and then seemed to run out of time.
You talked a lot about what push notifications are from an end user perspective, and in that much no different from polling performed by an app at all really? How are they different?
Can you tell us more about whether it is possible to characterize correct or desirable behavior for cases where users disable push on their devices? How does this differ per O/S in outcomes? Can an app detect if the user disables push, what should an app do when this is detectable?
And also for cases where users are offline and then get floods of push notifications, what should we look out for and what can we do to simulate stale state in notifications?
Finally are there any tools for us testers, how do we go about understanding ways to inject notifications or control and monitor perhaps.
1- Yes it is possible to check if user disabled push notification. What can app do in that case really depends on the Product requirement. Developers would be better in giving technical answer on how to handle it efficiently.
2- Usually bombardment of push notification can happen due to multiple factor one of them includes unsynchronized cron jobs other may be because of faulty code (which we need to test)
3- There are lot of 3rd party tools which can help in triggering push notification like firebase. Some large companies may have their internal independent tool to cater to their client with different push notification services.
So, I just want to be sure I’m not missing the obvious here, when I close the Facebook app, I still get notifications? I was a bit confused by what we mean by “backgrounding” which is a topic not actually covered thus far in the TestBash Mobile as I have been watching. Is it possible to explain more about why backgrounding is important and why or how it behaves differently on the platforms and also about Android app badges. Does iOS also have app badges and are badges linked to push notifications or just notifications in general?
So basically the OS will invisibly start any app that receives push notifications, but not show the app in the task tray? At least not until the notification gets accepted. The lifecycle here is the thing that is not clear.
There are lot of services running in the background. It depends on the purpose and key objective as there are background push notification also. Just to some up requirement may vary depending on the product (app).
Consider slack notification though it looks simple but it is quite complex.
“lots of services”. Do we mean each app has many services, or the OS has multiple internal background processes (aka services) I suspect the complicated answer testers get from developers (especially on SO) points to the eventually quite low testability we see for some kinds of functionality that users rely upon. I guess a good question to ask, is it possible to automate a way to toggle DND mode for example to verify that queued notifications don’t break an app? Or an alternate way to simulate the related test situations.
Well in my personal honest opinion we should not automate features like Push notification, OTP, two factor should not be part of automation as it can be time consuming. If you have Indepth knowledge in programming unit test can be written.
Very much with you on this one. Currently verifying a single-sign-on feature. It’s been a nightmare due to infrastructural constraints to test it. When automating login it’s wise to automate past these, cannot state that often enough.
However I’m always interested in ways that a user might break the app by manipulating some input or environment state repeatedly enough to cause either a security vulnerability or a crash. So we have to just explore carefully but fully.