Skip to main content

Testing Mobile Apps versus Websites


You all no doubt own a mobile phone, most likely an iOS or Android device, so you probably think it wouldn't be too difficult to test mobile apps. While the principles of testing remain the same, there are significant differences between how you test websites and mobile apps. For example:
  • You can't just open a browser on your laptop to test the latest version of the application. Somehow you need to get the latest version of the app onto your test device.
  • iOS and Android have completely different design patterns.
  • It's more difficult to get under the hood of an app to see what's going on. You can't just open Chrome DevTools.

This is the first in a series of posts where I'll give you some background on how to test mobile apps and include a number of tips and tricks that I've learnt the hard way in my 10 years of mobile testing experience. I'll focus on iOS and Android since those are the most common apps but I also test Windows apps. Note that I'm only considering how to test native apps and not web apps. Native apps are the apps that you install directly onto your mobile device from the Apple App Store or Google Play Store. Web apps are essentially websites that are accessed via the device's browser.

One of the first things to understand is that iOS and Android operate using different design patterns which determine button look and feel and where menus are placed. For example, traditionally Android has placed navigation menus at the top of the screen while iOS has tabs at the bottom of the screen. Also visual components such as check boxes, lists etc have their own styles.



There are also significant differences between iOS and Android in how you navigate. For example, iOS has no hardware back button but Android users use them all the time. In iOS you would swipe left to get a menu whereas in Android you would do a long press. You probably use one of those as your personal phone and would therefore be comfortable with that navigation pattern so when you are asked to test the other OS you will need to understand that pattern as well.

For a long time it was important to adhere to design patterns for each OS so that people who use the app can use familiar navigation patterns. However, in the last couple of years, the trend has been to move to a more uniform UX design especially if you are developing an app for both the iOS and Android platforms. So it is worth checking with your UX designers on what approach they have taken. The UX design approach will also affect how the app is developed. If you are developing separate native apps then you generally stick to the established OS design patterns but if you are using a platform approach such as Xamarin.Forms then the design would be more uniform.

The apps that I test are developed using Xamarin.Forms. It is a toolkit used for cross-platform mobile app development and runs on the .NET framework. It allows developers to create application code that is shared across Android, iOS, and Windows Phone. While the codebase is shared, it still allows OS specific customisation and produces native iOS, Android and UWP apps.

You need to establish what design decisions have been made before you plan your testing.

Most companies produce apps for both iOS and Android so you need to make sure that the developers are adhering to the relevant OS design pattern. For example, how does the app handle moving back up the stack? In Android, you would use the hardware back button but in iOS you need a software back button to return to a screen.

You might find these articles on creating and designing iOS and Android apps interesting:

In my next blog post I'll go into detail on how you test a mobile app. Firstly, how do you install a test app onto a device and how do you access files on a device.


Labels:

Comments

  1. halperinko21 November 2019 at 01:32

    This comment has been removed by a blog administrator.

    ReplyDelete

Post a Comment

Popular posts from this blog

Let’s stop writing automated end to end tests through the GUI

What’s the problem? I have not been a fan of Selenium WebDriver since I wrote a set of automated end-to-end tests for a product that had an admittedly complicated user interface. It was quite difficult to write meaningful end-to-end tests and the suite we ended up with was non-deterministic i.e. it failed randomly. Selenium Webdriver may be useful in very simple eCommerce type websites but for most real world products it’s just not up to scratch. This is because it’s prone to race conditions in which Selenium believes that the UI has updated when, in fact, it has not. If this happens, the automated check will fail randomly. While there are techniques for reducing these race conditions, in my experience it is difficult to eradicate them completely. This means that automated checks written with Selenium are inherently flaky or non-deterministic. Maintenance of these automated checks becomes a full time job as it is very time consuming to determine whether a failing check is actuall
7 comments
Read more

How I got rid of step by step test cases

In my last blog post I told you what I think is wrong with step by step test cases. In this blog post I’ll tell you how I got rid of step by step test cases at the company I work for. When I joined Yambay about 18 months ago, the company was following a fairly traditional waterfall style development approach. They had an offshore test team who wrote step by step test cases in an ALM tool called Test Track. Over the past 18 months we have moved to an agile way of developing our products and have gradually got rid of step by step test cases. User Stories and how I use them to test Getting rid of step by step test cases didn’t happen overnight. Initially we replaced regression test cases and test cases for new features with user stories that have acceptance criteria. The key to using a user story to cover both requirements and testing is to make sure that the acceptance criteria cover all test scenarios. Often product owners and/or business analysts only cover typical scenarios. It
3 comments
Read more

Non Functional Mobile App Testing

When you are testing mobile apps there are a number of non functional elements you need to consider (that do not apply to website testing) such as push notifications, device network issues, location services and app installation. In this post I'll cover these and explain how to test these areas. Push notifications Push notifications were pioneered by Apple in 2008 and this technology was subsequently adopted by Google for its Android OS and by Microsoft for its Windows Phone OS. Push notifications allow an app to deliver information   to a mobile device   without a specific request from the app. This means that the app does not need to be launched for the mobile device to get the push notification. Each operating system has their own Push Notification Service. On iOS it's called Apple Push Notification Service (APNs) and Android had Google Cloud Messaging (GCM) but this has been superseded by Firebase Cloud Messaging (FCM). Note that FCM can also be used to send push no
2 comments
Read more