Mobile Testing

An ASTQB-BCS Foundation guide

Rex Black

• Editorial: BCS, The Chartered Institute for IT
• Año: 2018
• ISBN:
  9781780174068
• Categoría: Ciencia de la computación
• Categoría: Control y garantía de calidad

Mobile testing is the process of testing the functionality, usability and consistency of mobile software. While similar to standard software testing, efficient and effective mobile testing requires an additional set of skills on top of those usually required by software testers.With this essential guide, in line with the ASTQB Certified Mobile Tester syllabus, you will gain the understanding and skills you require to begin your journey to becoming a proficient mobile tester.

1 INTRODUCTION TO MOBILE TESTING

In this chapter, we’ll lay the ground for the material to come in this book. We’ll start by talking about mobile devices, which are the platforms on which mobile apps run, and then about different types of mobile apps. Next, we’ll look at what mobile users expect from their devices and the apps running on them. This will bring us to the topic of how these mobile device and app realities, along with the expectations of the users, create challenges for testers, which will introduce a core set of topics for the subsequent chapters. We will also introduce the topic of tester skills for mobile testing, and then equipment requirements, both of which are topics we’ll return to later in the book. Finally, we’ll briefly look at software development life cycle models and how the ongoing changes in the way software is built are influencing model app development.

This book is not about software testing in general, but about mobile app testing in particular. So, while this chapter does not delve into the details of how mobile app testing differs from software testing in general, each of the subsequent chapters will explore those differences in detail.

CHAPTER SECTIONS

Chapter 1, Introduction to Mobile Testing, contains the following six sections:

1. What is a mobile application?

2. Expectations from mobile users

3. Challenges for testers

4. Necessary skills

5. Equipment requirements

6. Life cycle models

CHAPTER TERMS

The terms to remember for Chapter 1 are as follows:

• hybrid application;

• Internet of Things;

• mobile application testing;

• mobile web application;

• native mobile application;

• wearables testing.

1 WHAT IS A MOBILE APPLICATION?

The learning objective for Chapter 1, Section 1, is recall of syllabus content only.

First, let’s look at what a mobile device is. There are two types of mobile device—general purpose mobile devices and purpose-built devices, either mass market or proprietary. Purpose-built devices are built for a specific purpose or set of purposes. A smart watch is an example. Another example is the e-reader, though these are evolving away from purpose built to general purpose—consider Kindles. The newer Kindles are more like a fully-fledged tablet now than the original Kindles.

Proprietary purpose-built devices include the package tracking and signature devices used by various delivery services around the world. When you receive a package, you sign on the device itself. Once you’ve signed on that, you can go to the appropriate website, which will show that the package was delivered. Behind the scenes, the mobile device communicated to a server. That information in turn propagated to the delivery company’s online website. A pretty complex data flow happens in the process of doing something that appears to be fairly mundane: acknowledging receipt of a package.

Keep in mind that if you are testing a purpose-built mobile device or an application for such a device, everything we’re discussing will be applicable, plus whatever is specific and unique about your purpose-built device and its applications.

General purpose mobile devices are those that can run various apps, downloadable from app stores such as those for Android and Apple devices; can be extended with external peripherals, such as Bluetooth headsets and keyboards; can be used for a wide (and ever-growing) variety of tasks; and have a wide (and ever-expanding) set of sensors that allow them to interact with the physical world in ways that set mobile devices apart from the typical PC. Examples include smartphones, tablets, and netbooks.

In this book, we will focus mostly on general purpose mobile devices and the applications that run on them. We won’t talk much about “dumb” phones, since those generally support only calls and texts, with no ability to install additional apps. So, it’s unlikely that you’re building apps for a dumb phone.

There are two basic types of mobile applications. One type is a native mobile app. The other type is a mobile-optimized website. (It’s a little more complicated than that, but let’s keep it simple for the moment.) Native mobile apps run on your mobile device directly, while mobile-optimized websites run on your mobile device’s browser. Native mobile apps are downloaded from an app store and installed on your device. Mobile-optimized websites—including websites designed using responsive techniques—are simply websites that look and behave nicely on your device’s browser and hardware.

Some organizations have both types of mobile apps. For example, United Airlines and Delta Airlines have apps that you can download and mobile-optimized websites that you can reach at their appropriate URLs, either united.com or delta.com. If your organization goes down this route, it increases the challenge from a testing point of view.

Let’s consider how this has unfolded over time. Suppose you are involved with testing Delta’s online presence. About a decade ago, there was delta.com and the website there. That was the online presence. Whether with a PC or a smartphone or an internet appliance (if you know what that was), you’d go to delta dot com and you’d see the same thing. Of course, with a smartphone, you’d see it on a smaller screen and it’d be a lot more difficult to read and navigate. Then, mobile-optimized websites came along and companies started to build apps. So now, if you are testing Delta’s online presence, you have to deal with all three options: the mobile-optimized website, the normal website and the native mobile app. There are a number of things that you’d need to consider across those three different platforms. These are topics that we’re going to talk about in this book, so you can recognize and deal with those related, overlapping, but nonetheless different situations.

1.1 Test your knowledge

Let’s try one or more sample exam questions related to the material we’ve just covered. The answers are found in Appendix C.

Question 1 Learning objective: recall of syllabus content only (K1)

Which of the following statements is true?

A. All mobile apps are general purpose.

B. All mobile apps are portable across mobile devices.

C. Browsers are used by all mobile apps.

D. The number of mobile apps available grows by the day.

Question 2 Learning objective: term understanding (K1)

What is a native mobile application?

A. A mobile application that requires communication with the web server but also utilizes plug-ins to access device functionality.

B. A mobile application that is designed for use by a variety of devices, with the majority of the code residing on the web server.

C. A mobile application that is designed for a specific device family and is coded to access specific functionality of the device.

D. The actual physical device that is running a mobile application.

2 EXPECTATIONS FROM MOBILE USERS

The learning objective for Chapter 1, Section 2, is as follows:

MOB-1.2.1 (K2) Explain the expectations for a mobile application user and how this affects test prioritization.

On a typical morning or afternoon, when I’m working from my home office, you can find me in a gym, working out, and listening to a podcast on my mobile phone. I might be checking social media updates and the news while I’m doing this. As an aging gym rat, my workouts don’t require a lot of focus, as it’s mostly about maintaining a certain level of muscle tone and general fitness.

Often, I’m surrounded by younger folks who are still on the upward path from a health and fitness perspective, putting in serious gym time, dripping sweat on treadmills or lifting a couple hundred pounds of iron. But, when I look up from my phone, guess what? Most of the people around me are in the same position, head bent forward, looking intently at a small screen, Bluetooth headphones in their ears. Imagine how completely bizarre this scene would appear to a gym rat from the 1970s.¹

It’s not just at gyms. It’s everywhere. Worldwide, there is a new public health risk to pedestrians: being struck and in some cases, killed by cars because they—and sometimes the driver—were so engrossed in the little world of their little screen that they failed to avoid an obvious hazard.

So, public health and gym culture aside, what does all this mean for you as a tester?

Well, you should assume—if you’re lucky—that your users will interact with your app daily or hourly or maybe even continuously! But, before they do, you need to test it. Is it completely obvious how your app works? Does it work fast? Does it always work?

The further away your app’s behavior is from those expectations—reasonable or otherwise—the bigger the problem. There are millions of mobile apps out there, often with hundreds in each category. And in each category, for any one thing you’re trying to do, you’re likely to be able to find different options.

So, suppose a user downloads your mobile app, and, within seconds, the user’s not happy. Your app’s not very reliable. Or it’s too hard to figure out. Or it’s really slow. Or it´s really difficult to install or configure for initial use. What does the user do? That’s right: uninstall your app, download your competitor’s app, and, shazam, your erstwhile user is now a former user. Oh, yeah, and a dissatisfied one, too. Here comes the one-star review on the app store.

Now, some of you reading might have a captive audience, a cadre of users who can’t bail on you. For example, your company creates a mobile app that other employees use to do some certain thing. In this case, they can’t just abandon it. But if these users are dissatisfied, now two bad things happen. First, the company bears the cost of the inefficiency, the lost time, and the mistakes. Second, employee satisfaction suffers, because people compare your pathetic in-house app to all...