Everybody Tests

"No darlin', don't make me explain it. I don't know why but I don't want to." ~ Ted Hawkins Update: the included test system in Gradle supports parallelized test automation on all connected devices as of version 0.3. The current version is 0.7.3. See the following link . Obviously there is a lot of bluster about Google disrespecting scalable live device test automation which I could edit out at this point but A) Gradle Android support is not yet at v1.0 and B) that would be a wee dishonest. This is what I wrote. I was wrong. Check out Gradle. It is awesome-sauce! (edited: 2014-01-16) Android's developer documentation is excellent and voluminous. There is an excellent mix of training, API guides, and JavaDoc references. So it piques my attention forcing me to ask "why" when a large topic I'm interested in is conspicuously absent. With Xcode 5 and Mavericks Server , Apple has made a serious play to support the enterprise continuous in

Surprisingly, our device lab gets a lot of traffic. Many times this is in the form of a guided tour through the office for visiting clients or potential clients. The device lab is a regular stop even though many of our engineers rarely step foot in there. It is almost akin to taking guests on a tour of the server room. The difference is in this case, I've put effort into building an attractive display of all our connected devices. Beyond the display though, the task of visualizing the way in which the hardware on display fits into a Continuous Integration system like Jenkins is a tall order, even for technical people. The other day I was enjoying some Ikea-related humor  and it occurred to me that it would be cool to give the CI system the same treatment. So I give you Mobile CI: Illustrated a la Ikea assembly instructions. PHOTO SPHERE Photo credit: R.J. LaCount

In this admittedly niche topic of software quality assurance, I'm impressed at the traffic this tiny little blog has received. I'm thankful for the feedback so far and nothing speaks more loudly than the popularity of the few posts I've made on the topic of UIAutomator. They are by far the biggest sources of traffic. In order to help serve the common good of other QAEs working in Android, I'd be happy to explore the topic more deeply so I'm going to start a list of a few subtopics worth digging into. WebViews - this is a common area of concern for many people, especially on projects with low budgets for native app development. Whether WebViews can ever be supported or to what extent that can be supported by UIAutomator.jar is a topic that should get regular treatment. Useful UiWatchers - because these handle asynchronous events it would be useful to generate a library of common interface event Watchers that tests should be able to use in a generic fashion. It w

There are no clever quotes this time. Instead I'm just going to let you know that I've been in a high-fiving mood for hours now. Here's why... Android Device UI Automation Limitations In order to exercise the UI, the UI needs to be active. This means the screen needs to be awake and unlocked. All of the devices in my lab are required to be managed by the Google Apps Device Management Policy . This policy includes a maximum 30 minute screen timeout. Some devices retain a developer setting "Keep Screen On While Charging" despite the policy being in place. Some devices, especially the newer ones do not. It seems that the Device Policy overrides the developer settings and while I can see why that might be justified, it annoys me greatly. Since I do not have the privileges required to change the Device Policy, I have to work with it. Okay, more like *around* it. Try, Try Again I've tried many options to keeping screens unlocked. I've tried a variet

"Education is the key to unlock the golden door of freedom." ~George Washington Carver  The successful creation and management of a device lab at my company has required many hours of work from an autodidactic polymath. Unfortunately that responsibility fell to rest on me instead (with an audible *THUMP*). This is another piece of the narrative of my education. Waking and Unlocking Jelly Bean Devices Automatically One of the common traits to all Android devices we use in house is that they're all provisioned with a Google Apps account for remote management purposes. This includes "personal" devices (BYOD is alive and well) and lab devices. Under the auspices of Google's MDM scheme , there is no concept of segregating collections of devices and applying rules regarding PIN strength, screen timeouts, etc (at least according the the domain admin whose words I have no need to distrust). This is frustrating to me since my first experience with MDM was bac