There was lots of exciting presentations and enthusiasm for testing and test automation at Google’s Test Automation Conference. We had a privilege to attend this great event but also the live stream seemed to work pretty well during the first day. If you missed the day #1, here is a quick recap of the most relevant topics for mobile app test automation.
Google’s Kirkland Office
Real Devices vs. Emulators
One of the most common message during the first day’s presentations was this: there is an absolute need to test on real mobile devices (both, Android and iOS). If you listened to any of these presenters, nobody really advocated emulators. In fact, many of them were very straightforward about giving an advice to avoid emulators. Not only the real physical device due its hardware characteristics, but also because of network, user condition and real user experiences should be tested as well.
Focus was only on Apps and Web – missing one important target of mobile testing!
The event and all presentations focused on apps, web and technologies for those. Unfortunately, there was nothing for the no. 1 revenue driver on all mobile platforms; mobile games and how to test on those. We’ve gathered some data and insights from our experience in this popular blog series.
New frameworks – Appium!
The state of the nation in terms of test automation frameworks seems to be the same from last year. The most common frameworks (at least among Google teams) seem to be uiautomator and Espresso for Android and KIF for iOS. However, Appium was brought up in few sessions. In case you are interested get started with Appium, check out this tutorial.
Several of this years presentations mentioned that flaky tests are worse than no tests at all so many teams have focused on ensuring that the tests they have are 100% deterministic and will produce the same results every time. It seems that flakiness has less to do with a test framework used but more on how tests are written.
Many Google teams mentioned hermetic tests. In the context of mobile test automation this basically means simulating the server side responses so that the client side (i.e. the app) can be tested in isolation and the tests will focus only on determining whether the client end works as it should. This does not mean that the end to end scenarios are not tested but it enables identifying whether the failures are caused by errors in server side or client side.
Let’s see what Day #2 will bring to us. We’ll be reporting on Twitter and here on blog section all the most relevant pieces for mobile app testers!
Go through the basics of Calabash, how to create proper Calabash tests and how to make the most of them.Download