Skip to main content

Quality Assurance for mobile applications

By: Herak

Quality Assurance is an important aspect of Software Development Cycle and it has become even more important with the advent of mobile applications. This is because mobile applications are typically more complex and needs to be supported across a plethora of platforms. Often the same application needs to be coded in different programming languages to support different platforms for example Objective C for iOS and Java for Android. This results in multiple code base and requires multiple streams of testing. QA also need to pay special attention to ensure that the user experience of the app remains somewhat similar across the multiple environments. Thus traditional QA practices need to evolve to adapt to the needs of the mobile app testing.

In this article I am going to discuss the first two phases of QA, Preparatory Phase and Testing Phase. I will discuss how QA needs to adapt to the testing need of mobile applications and include links to resources which will help with the QA process.

Preparatory Phase

The Preparatory Phase is the phase when you prepare all the documentation and environments for the testing. This is the phase to ask questions about the business requirements and outline test plan and test cases.
There are three key steps in the Preparatory Phase phase

  1. Identify the target devices
  2. Create test plan and test cases
  3. Setup the test environments and devices

1. Identify the target devices

There are multiple devices in the market such as iPhone, Android, Blackberry, Windows Mobile, etc and each of these devices support number of versions of the operating system for instance iPhone supports iOS 3 to iOS 7 whereas Android supports 1.5 to 4.3. So it’s important to identify which device and operating system combination the application will support.

Make sure you have the answers to the following questions in the Business Requirement Document (BRD):
- Which devices are we supporting?
- Are we supporting tablets and smartphones?
- Which version of the operating systems are we supporting?
- Will the app have any functionality that may disabled in older versions?

The last two questions could be driven by the features of the application. For instance if the application uses any of the features in the latest iOS e.g. iOS 7 then the application needs to support the latest iOS. Then the question arises if the application should support any of the older iOS in a limited capacity i.e. with some of the new features disabled. QA should work with the Business Analyst or the Product Analyst to determine the target devices. The decision will also depend on the time allocated for QA and the application release date. This is important as there is a plethora of devices and operating systems combination out in the market.

Another key factor to take into account is the market share of these devices and operating system and the target geography. Visit the following link to StatCounter website to find the real time stat 

2. Create test plan and test cases

Use the answers to the questions in Step 1 to create a matrix to document the target device and operating system combination in the test plan. Then prepare the test cases taking all the information you gathered in Step 1 into account. The test cases for mobile application testing needs to be more high level as the tasks within a mobile app is typically very simple and can be executed with a few simple clicks.

3. Setup the test environments and devices

Install the necessary software development kit (sdk) such as Xcode for iPhone, Android SDK for android, etc.

Typically all these sdk comes with a simulator that can be used for testing.

Also resource the main target devices for the final round of testing. Even though majority of the testing can be done on the simulator it is still advisable to test the app on the key target devices every now and then to ensure the usability is consistent between the simulator and the app.

Testing Phase

Once the build is ready use the respective sdk to run the application on a simulator. Make sure there are no compile errors and if there are warnings go through them to make sure they are not anything significant.

Once the build is in a reasonably good shape deploy the build to the device. Follow the necessary process to deploy the build to the device. Go through the resources below to find more information about deploying the build to devices.

Steps to deploy app to iPhone:

Steps to deploy app to Android device:

Steps to deploy app to Windows device:

Steps to deploy app to BlackBerry:

Also pay special attention to the following when testing the app across the supported devices:

Apple iOS testing

- Make sure your app abides by the apple store review guidelines to avoid rejection. Here is the link to the review guidelines -

- Assure your app abides by the iOS Data Storage Guidelines

- Assure you app follows the Guidelines for using Apple Trademarks and Copyrights

Android testing

- Assure the android app follows the Android App Guidelines

- Follow the Android Launch Checklist to deploy the app to the Google play

- Assure the app abides by the Google Play Developer Program Policies

Blackberry testing

- Assure the app abides by the BlackBerry guidelines

Windows mobile testing

- Assure the app follows the windows mobile guidelines otherwise the app will be removed from the windows app store

In conclusion mobile app testing provides more opportunity for QA to flex its muscle and to play a more vital role in the software development cycle. At the same time QA needs to be more careful and assure the app abides by the guidelines of the respective supported environments in order to avoid rejection. I’ll discuss these guidelines in more details in my future post and will outline test cases based on these guidelines.    

Trending posts

Headless CMS - yet another CMS comparison

If you have used, or are familiar with the term headless CMS (content management system), then you will know the reason behind it. In summary a CMS is called headless because there is no Front end (FE), or output coupled with the CMS. Instead the CMS supports APIs which expose the content that can be consumed by external applications.                                                                 Photo by fotografierende from Pexels We could say that a decoupling from the CMS is provided, allowing, for those that have chosen this alternative, a certain sense of “freedom” in selecting the FE of the solution. There are many reasons for selecting the most popular, and so called “traditional” CMSs in the market. Even though, not sure if it is proper to call them “traditional” anymore as they keep evolving, becoming stronger and versatile and offering new services including SaaS. Even some are providing a flavor of headless. I have my fair share of experience using some of the greatest

Essence of email deliverability - SPF, DKIM, DMARC and segmentation

Recently I attended a lively discussion on email deliverability hosted by Litmus, one of the leading providers of email marketing tools. As email marketers one of the core metrics we often rely on is email deliverability and the discussion was around how to improve the email deliverability in today’s world where our audiences are ever inundated with emails. In addition we often find ourselves operating in a very competitive landscape vying for these audiences' precious attention. Photo by Ivan Samkov from Pexels   Hence it’s becoming increasingly important to ensure our emails are reaching our audiences’ inbox and driving engagement. This is why email clicks and engagement are strong indicators of the performance of our email campaigns instead of just the delivery rate of our campaigns partly thanks to Apple’s Mail Privacy Protection . So let’s start with the distinction between email delivery and email deliverability . This is very well articulated by Dimiter Batmaziam in the Li

Blue Ocean Strategy in the new reality

Photo by Kammeran Gonzalez-Keola from Pexels Since the COVID lockdown started over a year ago I have seen many restaurants in my neighborhood go through transformations - many became available in the top three delivery service: Ubereats, Doordash and Skipthedishes while the rest transformed to support pick up service and patio dining. However, among all of them, one of my favorite Indian restaurants impressed me the most.  The restaurant initially became available via the delivery services just after the lockdown in early 2020. I first ordered from the restaurant via Ubereats. In the delivery the restaurant included a pamphlet encouraging me to order from them directly on their website with an initial enticing offer. I ordered immediately after a few days from their website. I was guided to create an account and subscribe to their newsletter in the process.  The delivery for the order was on time and the food as always was delicious and of high quality. In a few days I received a

Goal setting frameworks for Product Management - OKR and HOSKR

As a business analyst and product manager we often use various frameworks to synthesize and organize our product ideas and goals. I think of frameworks as tools in our product management tool kit which we use depending on the task at hand.  And speaking of goals, OKR is a very popular framework that I often use to set the goals for the products I am managing. However recently I participated the #ProductCon conference hosted by Product School  and I stumbled upon one of the talks in which Rapha Cohen, the CPO at Google Waze introduced a more effective framework for setting product goals. The framework is called HOSKR.  In this post I'll describe both the OKR and HOSKR frameworks in more details using examples. I hope this will provide you, our readers, more practical insights on how to effectively use these frameworks to set your product goals.  OKR OKR stands for O bjectives and K ey R esults. If you are reading this post then you are on our Beolle blog and I am going to use one o

This blog uses cookies to improve your browsing experience. Simple analytics might be in place for pageviews purposes. They are harmless and never personally identify you.