Mobile Testing: An ASTQB-BCS Foundation guide

INTRODUCTION

I think there is a world market for maybe five computers. So said Thomas Watson, president of IBM, in 1943.

Back in the 1960s, when I was born, we already had way more than five computers. We even had spacecraft that went to the moon with computers on them, so we already had mobile computing devices. However, the Apollo Guidance Computer had 4 KB RAM, 72 KB of read-only storage, and a 2 MHz, 16-bit, single-core CPU. My current phone has 3 GB RAM, 32 GB of built-in storage and 128 GB SD storage, and a 1.8 GHz, 64-bit, six-core CPU. Back in the 1960s, we already had mobile phones, too, but they had to be installed in cars, because they relied on lead-acid batteries and drew 250 watts.

The marriage of mobile computing and mobile phones started in the 1990s, with the Simon Personal Communicator, the first phone with a touchscreen, email, calendar, contact management, and even the ability to add apps. Ironically enough, given Watson’s comments 50 years earlier, this was an IBM product. Fifty thousand sold. So, Watson’s prediction was off by four orders of magnitude just in terms of smartphones within 50 years.

In 2014, according an article in The Independent, the number of mobile devices officially passed the number of human beings. So, 70 years after Watson’s prediction, he’s already off by nine orders of magnitude.¹

The growth of devices is not the only amazing growth rate associated with mobile devices and their apps. The number of mobile apps continues to grow rapidly, and the number of hours spent using mobile apps per day is growing at an exponential rate. Mobile apps are being used for everything from entertainment to business networking to law enforcement to health-care management.

So, mobile devices and their apps are clearly on a stunning, transformative path. However, as mobile devices and their apps become more and more embedded in our lives, the consequences of failures goes up. From frustrations with slow, balky, or hard-to-understand apps to people being killed or injured, the stakes get higher and higher. At the same time, the expectations of users and managers, along with the pressures of a super-competitive environment, push for more and more functionality, faster and faster. In addition to all the things that usually make testing challenging, these opposing forces—high risks associated with poor quality versus a fanatical speed-to-market imperative—create huge additional challenges for us as test professionals.

So, if you are testing mobile apps, and finding yourself confronted with huge testing challenges, this book is for you. I don’t pretend to have all the answers—far from it—but I do hope to provide you with some answers and some good hints on how to find even more answers. The exercises, along with their solutions, will help you think through some of the challenges.

In addition, if you are looking to study for the ASTQB Certified Mobile Tester exam,² this book will provide a handy study guide for you. It covers the entire syllabus and includes study questions. Combine this book with an accredited training course (such as the RBCS Mobile Tester Foundation course), the syllabus itself and the sample exams you can download, and you should be well prepared.

Whether your objectives are work-related, certification-related, or both, I hope you enjoy this book, and find it a useful companion. Send me your feedback via your favorite social media app, running on your favorite mobile device. I look forward to hearing from you.

BOOK STYLE

You’ll notice that in each chapter I’ve included a list of terms to remember. You can check the definitions of these terms in the ASTQB and ISTQB® glossaries.

To be clear with respect to these terms, it is possible that you will get questions in the Mobile Tester exam that have to do with their definitions. It might be a question that simply asks, What is the Internet of Things? In that case, the correct answer matches the definition of the Internet of Things. However, it might be a question that asks about the application of a testing technique, but, to select the right answer, you also have to know the difference between a hybrid application, a native mobile application, and a mobile web application. So, you will need to study the definitions of the terms as part of preparing for the exam.

A note on learning objectives and knowledge levels

At the beginning of each section, you’re going to see learning objectives or LOs’. Each of those LOs has what is called a K level or knowledge level. What are learning objectives and knowledge levels?

The pedantic definition and use of a learning objective is to measure and quantify—to the extent possible—what and how deeply one should learn from a training course or book on the topic, and what and how profoundly one should know a particular topic to pass the exam. The ISTQB® 2018 and the ASTQB have adopted this concept for their syllabi, in part to ensure consistency of exams around the world and also to aid in achieving consistent training courses.

So, the Mobile Testing Foundation exam is based on learning objectives, and the same learning objectives underpin this book. We’ll introduce the learning objectives for each section at the beginning of that section.

The learning objectives are at four levels of increasing sophistication:

•K1: remember basic facts, techniques, and standards;

•K2: understand the facts, techniques, and standards and how they inter-relate;

•K3: apply facts, techniques, and standards to your projects;

•K4: analyze a scenario to determine which facts, techniques, and standards apply to the scenario.

Let me explain the difference between these K levels with some examples. First, let’s look at the difference between K1 and K2. Obviously, in order to understand something, you’d have to remember it. However, understanding is a higher level of knowledge than remembering. As an example, I went to UCLA and got an engineering degree there. Part of that degree program was a two-year-long, six-class series of math classes. It started with basic calculus, derivatives, and integrals. It culminated in a class on matrix mathematics and related topics.

I really hated that class. I still sometimes have a nightmare that I’m going to my final for that class, with visions of matrices and eigenvalues and matrix inversions and so forth swimming around in my head. In my nightmare, and in my real life now, I remember what those are, but don’t understand them. So, I have K1 knowledge of matrix mathematics left over from that class, but no K2 or K3 knowledge, which I had (just barely) at the time of the final. In real life, I remember walking out of the final, thinking, Thank God that’s the last in that series of math classes, because if there were one more level of difficulty beyond that, I would not be able to be an engineer.

Now, let’s look at the difference between K2 and K3. Again, obviously, you can’t apply a technique without actually understanding it, but just because you understand something doesn’t meant that you can apply it. As an example, similar to the two-year-long series of math classes, we also had a two-year series of physics classes. One that I remember particularly well covered topics like harmonics, how springs work, how musical instruments work and so forth.

I found those topics fascinating for some reason, and the material has stuck with me to some extent over these years. I can explain to you how a piano or a violin works. However, can I calculate the harmonic frequency of a guitar string? No. I have K1 and K2 knowledge of how musical instruments work, but I have no practical ability to apply that knowledge to do anything; that is, I have no remaining K3 knowledge.

In terms of the difference between K3 and K4, in a K3 situation, you must be able to apply your knowledge, but you are told in advance what knowledge is required. In a K4 situation, you must determine what knowledge is required first. For example, if you tell me that you have a table with numbers showing the velocity of an object over a period of time, and you need to determine its rate of acceleration, then I would know how to set up a table in a spreadsheet to get an equation for the velocity, and then use differentiation (differential calculus) to find the acceleration, because I still have K4 knowledge of basic calculus stuck in my head.

What kind of exam questions can you expect? Different exam and national boards can have somewhat different exams. However, the following rules of thumb should hold for most exams.

The entire Mobile Tester Foundation syllabus is implicitly covered at the K1 level, which means that K1 knowledge of the syllabus can be necessary to get the right answer for any question in the exam, though the question may also require K2, K3, or K4 knowledge as well. There are 40 questions in the exam. Approximately speaking, 25 percent of those questions are K1 questions, 50 percent are K2 questions, 25 percent are K3 questions, and there is a single K4 question. Like the Foundation exam and unlike the Advanced exams, regardless of K level, each question is worth one point. You will need 65 percent to pass the exam, which might seem easy, but the questions can be hard.

While the ISTQB® Foundation syllabus 2018 is not directly examinable, there will be questions that relate to material covered in that syllabus. Therefore, I strongly recommend reviewing the ISTQB® Foundation syllabus 2018.³

¹You can find the referenced article online at: www.independent.co.uk/life-style/gadgets-and-tech/news/there-are-officially-more-mobile-devices-than-people-in-the-world-9780518.html

²See https://certifications.bcs.org/category/18802

³You can find the Foundation syllabus here: www.istqb.org/downloads/syllabi/foundation-level-syllabus.html

1INTRODUCTION 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 the other cool apps they have on their phone. Eventually, these bad things come home to roost with the development team that created the hated app and inflicted it on the other employees.

I have a client that operates a chain of home improvement stores. They have both a brick-and-mortar presence and an online presence. Doing business purely online doesn’t make sense, as sometimes you need a rake or a shovel or a sack of concrete right now.

Now, if you’ve been in a large home improvement store, you probably know that it’s not always obvious where you find particular things. In addition, sometimes stuff gets sold out.

So, my client issued iPhones to all its associates, and installed a custom-built app on them. If a customer approached an associate and asked, Where are your shovels? the associate could say, Shovels are in this particular aisle, this particular location.

In fact, the associate could even add, By the way, we’re sold out of square-point shovels, but we happen to have some available at our other store at such-and-such location. That was because the app was able to communicate with the back-end inventory systems. The app knew that the current store didn’t have something in stock, and automatically found the nearest store that had it. Further, if the customer didn’t want to drive over and get the square-point shovel, the associate could use the app to send