Mobile testing web apps - device coverage importance

In the case of testing Web applications- on mobile devices from your experience what factors other than screen size have influenced the performance, functionality, and usability of your application?
I suppose I am asking principally does the ram and/or processor have an effect on things?
Do you find you feel the need to test web applications on a range of devices to cover all factors such as ram and chips etc? Have you ever found issues that only appear on a specific device?


Where I work we have a native app, so never had to worry…but the same problems exist. Grab a low spec device (Android GO devices are a cheap device that runs an Android fork, so it’s Android, but cheaper and mostly works the same.) and do some experience based testing on it. Our app is very different in function, so tooling to test things is also pretty much non existent, and so it very much becomes based on testing in the wild. For example getting a speed or frames per second impression is terribly hard on mobile, harder than it needs to be. Often the only way is to run he app under test for long periods, and then look at the power metrics manually. I really wish I could be more specific, very few people ever share their actual tips for doing this, because it’s very context specific. You want to follow @dnlknott , some good material he posted on the “Pro” MOT section too.


You should also keep the different browsers in mind. They use different engines, which may have an impact on your application.


Indeed. @dnlknott’s MOBILE APP TESTING mnemonic is incredibly helpful for all things Mobile Testing.


Thanks for the reply.

1 Like

Hi Daniel!

I’ve had a look at your MOBILE APP TESTING mnemonic and it has given me some great ideas! I’m currently testing a web app that is accessible on mobile/tablet via Chrome/Safari/Firefox and I was wondering whether this kind of app also requires testing of things like interruptions?

At the moment i’ve not had any real devices to test with and have been using things like the responsive developer tools and BrowserStack. If there is risk associated with a web app when it comes to things like interruptions and the type of network you are connected to maybe I need to get my hands on some real devices!


So. A little horror story, to keep you up at night.

It was the week before shipping and all through the night 
 , the coders were coding and testers did test.
The release process was tight but the app store just 
  , needed to approve and they looked forward to a rest.
But that night the CEO was less than impressed
   , he tried out the app on the old phone that he had.
He installed it and started it and soon was disgusted
  , the tiny screen on his phone made it look really bad.
Their ship date got postponed 
 , and the graphics team were berated.
Fixing it at once the were all told
 , that made the dev team quite deflated.


So yeah, you are wasting peoples time if you don’t get a variety of devices and test in real life workflows. Just read up on the hilarious bugs in the early versions of the Uber hailing app for examples of how not to test your mobile app in a simulator.


Testing for accessibility I would always recommend to test on a real device. It’s such a big difference on a real one. Depending on the accessibility implementations of course.