In every year since 2011, we have devoted one edition of our magazine to the topic of mobile testing. In this year’s issue on mobile, we focus on testing from the point of view of the user experience.
Most teams start with UI testing, and it may seem basic — until you look at the importance and uniqueness of UI testing for mobile apps and websites. There’s a lot to understand, but the most important thing is that mobile users aren’t very bug tolerant. Their expectation is flawless performance.
First, the problem of mobile responsiveness. The Wikipedia definition of responsive web design (RWD) is: …”an approach to web design aimed at crafting sites to provide an optimal viewing and interaction experience — easy reading and navigation with a minimum of resizing, panning, and scrolling — across a wide range of devices (from desktop computer monitors to mobile phones).”
Responsiveness testing is key for any mobile software product. That is the ability for your site UI to be accessed by all the defined devices with varying screen sizes and orientations (portrait or landscape). This is different from functionality or even UI testing, since UI testing focuses on the correct behavior of UI controls such as combo boxes, text boxes, buttons, or links. Responsiveness testing examines the layout and look and feel of, for example, a 12.9” iPad vs. a 9.7” iPad, not UI functionality.
Second, what mobile devices do you test? I just had a new client request that I specify what platforms to use for mobile testing. That is a huge question with no easy answer. The mobile world is increasingly fractured. The devices, operating systems and browsers, rather than converging, are becoming increasingly diversified. There are so many manufacturers making devices with varying hardware components. For example, if your app uses geolocation, do you have to test devices’ gyroscopes or accelerometers, gravity sensors, compass sensors and magnetometers? It’s a complicated answer.
So many devices, and so little time. How many devices do you need to test? How and where will you execute your tests? On real devices? Buy a Cloud service? Use emulators? At the UI? At an API? We have been having these problems in mobile testing since it began. The same issues are here today and it is getting ever more complex as the device world diversifies.
These problems would diminish, or go away entirely, with a convergent mobile device market. But not only is the device/hardware market fracturing, the OS world is getting more complicated as well. For the Android OS alone, the various versions of Lollipop, KitKat and Jellybean all have significant usage, with lesser use of Ice Cream Sandwich and Gingerbread. They are definitely not all the same. So for Android, what do you test?
Companies continue to struggle with a mobile testing strategy. There are more questions than answers, and this is not necessarily a bad thing!
As I learned from my first and greatest testing manager, Cem Kamer, “half of our job is education.” Wow.
Bring your test strategy and coverage plans to the team. Educate your team to these complexities. Marketing, POs (product owners), product management, as well as programmers have to be involved in your decision-making. What you test — the hardware, sensors and screen size, and OS combinations — as well as how to test — emulators, cloud, real devices — needs to be knowledgeably and openly discussed and then agreed upon.
In these Agile and Lean days of no or few test plans, someone has to be having these conversations; someone has to be asking these questions. That person is you.
Our last issue of 2015 will be on Test Automation. That issue will also contain the Editorial
Calendar for 2016. Until then, good luck and have fun testing!
