Android App Testing Android App Testing

Contact Me Your next step – Contact Me

Contact Me

Contact me for freelance Android App Testing & QA Services

I'm a freelance Android App Tester.
Contact Me

My other testing services: iOS App Testing / Website Testing

How an Android App Testing Project works How an Android App Testing Project works

In some cases, a client will know exactly what they want from an Android app testing project and this will help to define the project from the start. On the other hand, a client may come to me and say ‘test my Android app’, in which case, further information is required to find out the required scope of the testing project.

In order to define the project, we can discuss requirements via email, phone call, Skype call, Slack chat, MS Teams etc.

The aim here is to agree what the testing should focus on and on what devices the testing should be carried out on.

Other factors to consider are scheduling, the app delivery method to use, also where issues are to be raised and how test results are to be reported.

At this stage, the Android App is tested, according to the Project definitions and the device list agreed on. This will include all the testing types agreed on, plus the appropriate amount of Exploratory Testing to unearth bugs which may otherwise be left lurking in the Android App.

Issues are raised as they are found, in the method agreed: this could be in your own issue tracker – such as JIRA, DoneDone, RedMine etc – or within an Excel document, or perhaps a Google doc, or, where applicable, within my own hosted JIRA issue tracker.

Test results can be reported in many ways and the method used will often depend on the length of the test project. For example, a short half-day test could be reported on in an email that summarises all the results, whereas a longer test could be reported on in a full Test Summary Report.

A Test Summary Report includes sections such as Overview, Main Findings, Gap Analysis, Deliverables, Testing Types Performed, Test Devices, Bugs Statistics and Summary of Main Bugs.

At this stage, we can discuss if any further testing is required.

This may include further focussed testing, retesting of fixed issues, regression testing after changes or any other type of testing.

Other testing types I perform: iOS App Testing, Website Testing

Testing Stages

During the Development Stage, I can work with the Developers, Designers and Project Managers to effectively design and execute tests at the most cost-effective time.

    * Working with Developers, Designers, Project Managers.
    * Testing can be focussed on the most important functionality or can be generalised, to cover all areas of the app.
    * Testing can be added in phases, as new functionality is developed and available for testing e.g. on a sprint/iteration/release basis.
    * Most cost-effective time for testing.
During the Beta Stage, bugs can be found which otherwise would have been released to the public.

    * Find Bugs before App is released to the public.
    * All functionality can be tested at this stage, and emphasis can be given to certain functionality depending on priorities.
    * Still a cost-effective time for testing.
At the Release Stage, testing can be done at and around the go-live stage, to try and find any last-minute issues, and also when new features are added to the app, or when the app is rewritten to take into account new technology, new features etc.

    * Testing at and around the go-live stage, to find any last-minute issues
    * Testing new Features and Functionality
    * Finding Bugs in rewritten Apps

Android App Sectors I have tested in

  • Communications
  • Retail & NFC Payments
  • Email
  • Field Service
  • Health & Leisure
  • Cinemas, cinema ticket booking
  • Sports – Golf & GPS
  • Fitness Tracker
  • Retail & Shopping
  • Shopping Rewards
  • Financial
  • Games
  • Casino
  • Poker
  • Music Industry
  • System Utilities

Android App Testing related activities & technologies

There are many ways of distributing Android Apps that require testing. This would normally depend at what stage of development the app is at – development, beta, post-release etc – and also what platforms the developers use.
Crashlytics is an excellent platform for both distributing apps and also – it’s main use – for Crash reporting. To enable app distribution, the tester is signed up to the dev team as a tester and then installs the Crashlytics Beta app to enable the app install on the relevant device(s) From within the Beta app, the tester can see all the apps they are signed up to test and can then install them. I’ve also used TestFairy for Android app distribution.
Other methods of Android App Distribution include the HockeyApp platform (now owned by Microsoft), also released apps via the Google Play store and apps can also be distributed by email – where attaching the APK file allows the receiver to install the app on their Android device, via Install Now.
A crashing Android App is seen as the most serious type of bug – usually treated as criticial/show-stopper – especially if it happens on multiple devices.
There may be many different reasons for the crash, so the developer will want to know as much information about the crash as possible, so they can attempt to fix the issue. This information will usually include both a description of what the tester was doing in the App at the time of the crash, the exact time of the crash and also any accompanying crash logs from the device.
As mentioned in Android App Distribution above, the Crashlytics platform provides a method of both Android App distribution for testing and also crash reporting and analytics.
Other ways of getting crash logs from an Android App is to use an App like aLogcat, which allows you to see the log information and then use that information, by emailing it or copying/pasting it, perhaps for use in a bug report for an Issue Tracker. The app Crash Report performs a similar task. Another way is to run the app along with the Android SDK and then obtain the crash reporting information that way. (Note: Some of these methods no longer work in later versions of Android)
Most Android Apps are written in the Android SDK, which is based on the Java programming language. I have a good knowledge of Java and the Android SDK, having studied both areas and have also dabbled in creating some test Android Apps. This gives me a useful insight into the technology used and the various parts of Android Apps – such as Activities, Intents, Views, Content Providers etc.
Creating Test Plans and Test Results documentation is a vital part of the testing process and enables the tester to plan what to test and to keep track of what’s been tested.
Creating detailed Bug Reports is an essential part of the testing process, allowing the developers to reproduce the bug and then attempt to fix it.
Sometimes a bug is best shown via a screenshot or a video – or both – especially when a text description doesn’t seem sufficient or would be too complicated to be useful. There are several different methods for getting screenshots and videos of Android Apps in use, ranging from testing with the Android device connected up to the Android SDK, to using another device to record them.
Maintaining and tracking issues in an Issue Tracking System is a vital way of managing the Test Process, so that progress in fixing issues can be monitored and updated.
Different projects require the use of different Issue Tracking Systems. So far, I’ve used the specialist Jira system, the Redmine issue-tracking system, the DoneDone issue-tracking system, the issue-tracking features in the Codebase system, plus have also used Excel spreadsheets and Google Docs.
As the Android platform has matured, new technologies have been added to the Android ecosystem and other concepts have evolved, such as IoT. These technologies are sometimes used within Android apps and therefore require specialist testing.
Android Pay – Google bills Android Pay as “Pay your way. Shop how you want” and it allows users to make payments both in stores and in apps, similar to Apple Pay. It uses a combination of Near Field Communication (NFC), plus one of a PIN code, password or pattern to authenticate.
NFC – NFC is a method of wireless data transfer between two enabled devices that are in close proximity (about 10 cms) An NFC-enabled device will detect another NFC-enabled device and data can then be transferred between the two devices. In the real world, NFC is technology used in ‘Tap and go’ or ‘Proximity card’ services – including Apple Pay, Android Pay and Samsung Pay, plus many other services.
IoT – The Internet of Things (IoT) refers to the interconnection of physical objects or “things” which contain network connectivity, sensors, electronics and software and are enabled to exchange data with smart devices, such as smartphones and tablets – this then enables them to be app-controlled.

Featured Posts From The Blog

  • iMac M1 image

Testing iOS apps on iMac M1

Now that I've added an iMac M1 to my test lab, I can test iOS apps on it. This is because it's using Apple silicon and can run iOS and/or iPadOS apps, that are either [...]

  • Happy New Year

Testing projects 2021

As we're about to say goodbye to 2021, I thought I'd provide an overview of some of the testing projects I've worked on this year - its quite varied as you can see below, from [...]

  • MS-Auth-app

Testing Authentication Apps

What is 2FA? 2FA is two-factor authentication and means you are using two of the three standard authentication methods (a password or similar, an authentication token or app, a fingerprint/face or other biometric factor) This [...]

  • Security-Testing

Basic Security Testing

High profile websites being hacked is nothing new nowadays - we hear about a different hack every week, if not every day. Hackers will use many different techniques to break into high profile websites and [...]