In this post I will describe how to build your own Android device cloud in the office. You may think this is expensive and will take lots of time and work, but I promise it isn’t. After installing the device cloud you are able to control the real Android devices from your web browser no matter how far you are away from the real device. For all iOS testers and developers out there, I must say sorry, this post is only handling Android devices until know the tool I will use is not supporting iOS. Before I get started with the installation and setup I list shortly the hardware and software I used to setup the whole system.
Hardware and Software
Lets start with the software that is managing the Android devices. The software is called openstf, where STF stands for Smartphone Test Farm. The software is open source and is maintained by Simo Kinnunen and Günther Brunner. STF offers a plethora of really cool features like Read more
This article contains excerpts from my book „Hands-On Mobile App Testing“ published with Pearson Education.
As you can see in the following image, the typical pyramid consists of three layers. At the bottom, there is the automated unit-testing layer, in the middle the automated integration testing layer and at the top there is the automated end-to-end testing layer (including the user interface tests). Each layer has a different size, indicating the number of tests that should be written within each stage. Manual testing is not part of the test pyramid, hence it is shown as a cloud for additional testing work.
But this pyramid is not applicable to mobile apps and mobile test automation. Mobile testing requires a totally different set of testing activities like movement, sensors, different devices and networks compared to other software like desktop or web applications. Lots of manual testing is required to be sure that a mobile app is working as expected in the different usage scenarios. Read more
The 38th issue of the reading recommendation contains five interesting posts. This issue is mainly about learning, test automation and how to select the right mobile test devices for your team. There are posts with the topic “Audio Testing”, “Remote Experiential Learning”, “5 Things Your Boss Doesn’t Understand about Test Automation”, “Automated Verifications are Special, and Why This is Important” and an article about “How To Decide Which Devices to Buy for Mobile Testing” from Karen Johnson.
Enjoy reading the posts and send me posts that are worth reading and I will mention you and link to your social links or blog.
Google Testing Blog: Audio Testing – Automatic Gain Control
You probably all know that Google has started with the rollout of Android M (Marshmallow). Android app developers and testers must know the new features that are coming with the latest version of Android M. Next to the brand new permission system, Android M also introduces Doze and App standby to save battery.
If a user leaves a device unplugged and stationary for a period of time, with the screen off, the device enters Doze mode. In Doze mode, the system attempts to conserve battery by restricting apps’ access to network and CPU-intensive services. It also prevents apps from accessing the network and defers their jobs, syncs, and standard alarms. Periodically, the system exits Doze for a brief time to let apps complete their deferred activities. During this maintenance window, the system runs all pending syncs, jobs, and alarms, and lets apps access the network. (Source: Google documentation)
In order to be sure that your app is able to handle Doze and app Standby, Google provided some documentation on that. Here are the steps to make sure your app handles Doze (instructions copied from the documentation):
Testing your app with Doze
You can test Doze mode by following these steps: Read more
My colleague Denys Zelenchuk has developed a very helpful Android app called Bug Radar. The main task of this app is to monitor any app that is running on a test device. Whenever the app under test is crashing or not responding (ANR), Bug Radar notifies you about the problem in the notification center and is creating a error report file including the stacktrace and the device info. The report will be saved on the device in the Bug Radar folder and can be send via email for further investigation. Read more