Android App Testing

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.