Ein Muss für jeden mobile Tester!

2014-09-30 14_42_42-Hands On Mobile App TestingDaniel Knott hat seine langjährige Erfahrung im Bereich mobile Testing in ein Buch gepackt. Seit kurzem ist es nun digital fast DONE. Ich hatte die Ehre beim Review einiger Kapitel beteiligt zu sein und kann daher sagen: Klasse was Daniel da elektronisch zu Papier gebracht hat. Das Kapitel “Mobile test automation and tools” alleine ist es Wert das Buch zu kaufen. Ein Muss für jeden mobile Tester!

Mobile Test Automation – a few questions to ask

michael_palotas_shortGastbeitrag von Michael Palotas, Gridfusion


Too many decisions around tools for automation are taken on the golf course, rather than sitting down and thinking through what an organization really needs. Below is a small compilation of topics and questions to ask yourself before deciding and investing into a specific tool for mobile test automation.

Do you have existing automation infrastructure, which you want or can reuse?

Is there is already an existing infrastructure or tool set for your web automation that you might want to reuse? Especially when it comes to bringing the web and the mobile world together, it makes sense to drive your tests out of one infrastructure rather than building up silo tools for mobile (and potentially even for ios, Android etc.). How does the mobile automation tool fir into this existing infrastructure / ecosystem?

Which platforms do you want to support?

Android, iOS, Windows Phone, … – You need to be clear where your revenue is coming from – or potentially will come from. There are many tools out there that support one platform better than another, in a less elegant way, or not at all. So make sure that the platforms where you make your money are equally supported by your automation tool.

Devices or Emulators?

In my opinion, a mobile automation tool must support both – devices and emulators. Many – especially commercial tools – do either one or the other. If you only support devices then you are quite limited on scaling options and simulating i.e. different network behavior, locations etc.

On the other hand running only on emulators / simulators doesn’t give you the “real” feel for the applications. That said the look and feel of an app is still best evaluated by a human and not a machine. So there are also things that simply should not be automated in the first place.

Mobile Web, Native App, Webviews

Be very clear about what your mobile world actually consist of. In many cases there is a mobile website and also a native app. Inside your native app there are often times web views where you will need to switch context between native and webview. Make sure your tool actually supports all of that, as you don’t want to figure out half way trough your test that you get stuck because your tool can’t switch to a web view.

Modification of your native app

Numerous tools require you to instrument / modify your mobile application. That enables them to connect and interact with your app. One thing to remember is that when you modify your app, it may cause some side effects in the behaviour of the app. Since you don’t exactly know, how the instrumentation works you may be up for some surprises. Therefore my preference is to use tools that do not require app modification.

Think about scaling, right from the beginning. This doesn’t mean that you need to scale right away, but make sure your tool supports it. Your mobile business may be small at this point, but (hopefully) it will grow and with that you will probably need to run more tests, support more devices etc. Since we are talking about end to end tests, a test can easily take a few minutes. Without scaling, it doesn’t take long and your execution time for a suite takes hours. In the spirit of agility where fast feedback is essential, you simply cannot afford to wait for your test runs for hours.

Test stack integration

Be very careful with this one. In an agile world, where testing and development are moving closer together, the last thing you want to do is to create a tool silo, that excludes developers from using the whole tool stack. In my opinion it is essential that an automation tool can be fully integrated into the entire development stack, so that developers and testers can work on the same tests and codebase.

Continuous Integration support

Can you hook your automation tool into a continuous integration system? Simple question but it can be game changing. As mentioned before, agile teams rely on fast and frequent feedback, and therefore continuous integration is not an option. That makes it a no brainer why your automation tool should also be able to be hooked into a CI.

Reporting capabilities

Running your tests is nice, but you probably also want to look at the results. Have a good look into what the reporting capabilities of your tool are. Screenshots are essential but you also may want to have the option to dig deeper into your app.

Programming languages

You need to have a close look at the programming languages supported by your automation tool. Ideally you can use the same programming language which is used for your “regular” code as well. That way you can reuse most of your already existing development and build infrastructure.

Jailbreak / Rooting

Many mobile automation tools require to jailbreak or root your device in order to run tests on it. Again, you need to evaluate how important it is to run your tests on “off-the-shelf” devices vs. devices that have been significantly modified and therefore may behave very differently.

Runtime inspection / debugging

This last point is important when you need to be able to stop the test mid way and debug it. Debugging comes in handy i.e. when you want to inspect the content of your native app or you don’t know the exact locators .

Bottom Line

I hope the above questions gave a little indication of what kind of questions to ask yourself (and your tool vendor) before you jump into an investment. Mobile automation potentially comes with a significant investment and you don’t want to find out half way through that you picked a tool that does not support portions of your mobile business.

GRIDFUSION ist Partner der 1. Mobile Quality Night Vienna

GRIDFUSIONpng_72Selenium Proof of Concept bevor Sie investieren.

Möchten Sie Open Source Tools für Ihre Testautomatisierung verwenden? Sie wissen aber noch nicht ob es das richtige für Sie ist? GRIDFUSION bietet ein “Proof of Concept” für die Verwendung von Selenium in Ihrem Unternehmen an. Typischerweise dauert ein Proof of Concept zwischen 3-5 Tagen. Während dieser Zeit evaluieren wir Ihre Applikation zusammen mit Ihnen und automatisieren sie mit der Selenium Toolfamilie. Im Anschluss haben Sie ein klares Bild, ob der Einsatz von Selenium bei Ihnen im Unternehmen Sinn macht. Proof of Concepts sind voll funktionsfähige Software, die auch als Grundlage für die weiterführende Automatisierung mit Selenium verwendet werden können.

EBCONT proconsult ist Partner der 1. Mobile Quality Night Vienna

2014-09-27 09_56_24-Leistungen - EBCONT proconsultEBCONT proconsult steht für umfassende Beratung in der IT Welt – von der Bedarfsanalyse über die strategische Beratung, der Umsetzung samt Qualitätssicherung bis hin zur Wartung betreuen wir unsere Kunden aus einer Hand.

EBCONT proconsult ist Partner der 1. Mobile Quality Night Vienna und unterstützt die ASQF Fachgruppe Mobile Apps & Devices (aka Vienna Mobile Quality Crew), Die Vienna Mobile Quality Crew vereint all diejenigen, die ihre Erfahrungen und ihr Wissen rund um Mobile Apps Development austauschen wollen.

Lightning Talk@Vienna Mobile Quality Night – Selenium 3 und die Zukunft mobiler Testautomatisierung

selenium-automation-testingSelenium 3 wird – wenn auch später als ursprünglich erhofft – stärkeren Fokus auf mobile Testautomatisierung legen. Es wird sich zeigen, ob damit endlich eine stabile und standardisierte Automatisierung von mobilen Applikationen möglich wird.

Das Selenium dafür grundsätzlich das Potential hätte, zeigte es eindrucksvoll im Bereich der Webautomatisierung. Hier wurde das Kommunikationsprotokoll sogar zu einem offiziellen W3C Standard erhoben. In diesem Lightning-Talk wird Stefan Gwihs, ANECON Software Design und Beratung GmbH, den aktuellen Stand der mobilen Testautomatisierung mit Selenium und die geplanten Änderungen mit Selenium 3 vorstellen und eine mögliche Zukunftsprognose abgeben.