Bei der diesjährigen Mobile Quality Night Vienna wird Dan Cuellar (Bild) – der Erfinder von Appium – den Bring Your Own Testautomation (BYOT) Track mit einem Keytalk einleiten. Rudolf Grötz, der Organisator der Mobile Quality Night Vienna – traf sich mit Dan auf einen (virtuellen) Kaffee um ein wenig die Geschichte von Appium zu beleuchten.
RG: Dan, you are the creator of Appium. Tell us something about your inspiration to create a new mobile test automation solution!
DC: I had just started a new job at Zoosk in the autumn of 2011. One of the biggest challenges we were having at the time was the length of our mobile test passes. I couldn’t cut the amount of testing we were doing because of the cost of a mistake on iOS. If we shipped a bad bug, it could be a week until the App Store would allow us to push through a patch. Running manual tests on mobile devices was also much slower and more taxing than in a browser. Humans are not meant to use a mobile phone for 8 hours a day, several days a week.
RG: When did you realize that other testers are running into the same problems with mobile test automation?
DC: I was selected to speak at Selenium Conference in London in 2012 about an entirely different topic. As part of my presentation, I happened to show a demo of a test running on iOS and Chrome for OS X using the same exact test code. For the rest of the first day of the conference, someone approached me every 30 minutes or so asking how I got an iPhone test to run with Selenium-like syntax. Several people mentioned that I should sign up for a lightning talk on the last day of the conference and show it to all of the attendees.
On the last day of the conference, I got up to do my lightning talk and my laptop was malfunctioning. I remember Jason Huggins, the creator of Selenium, was moderating the lightning talks with a strict time limit of 10 seconds to get the projector working or the talk would be skipped. He started counting down and I think he had just said 1 when finally my screen clicked on and I was able to start the presentation. I’ve always enjoyed the irony that Jason, who eventually played a huge role in getting Appium going, also almost killed it before it ever got off the ground.
RG: Then Jason Huggins came onto stage?
DC: So, after I gave the lightning talk, I didn’t hear anything from anyone for several months. I sent out the source code in C# to a few people, but I don’t think anyone could comprehend it; in hindsight, probably because the open source community tends to not work with MS technologies too often. Eventually, I did get a call from Jason about 4 months later, who told me to meet him in a bar in SoMa in San Francisco. I showed up and explained to him and some of the developers at Sauce Labs how it worked and since they didn’t know C# either, I showed them the prototype version I had written in python way back when I was trying to figure out if it was possible.
Once Jason got the python code in his hands, things really started to happen. He posted it on GitHub and he got a few contributors form outside his company to join in. Things really started to move. Dante Briones, who had seen the demo in London, invited me to speak at the Mobile Test Summit in San Francisco later that year. I recall at that conference, meeting everyone who created most of the relevant tools today in Mobile Automation.
RG: After Mobile Summit 2014 you presented iOS Auto as Appium. Why did iOS Auto get a new name?
DC: Jason always told the story of how he regretted not getting to name Selenium what he actually wanted to call it. I believe he wanted to call it CheckEngine. The gist of the story is that the community went and ran with the name Selenium after a comment someone had made about his tool when comparing it to another tool called Mercury.
Anyways, he suggested that the project get a new name now because the current name was unlikely to stick, not SEO friendly, not available as a twitter handle, etc. Many ideas were thrown out and we settled on AppleCart. A day later, while Jason was reading some of Apple’s guideance on copyright and trademarks and noticed that under the section of examples for names Apple would defend its trademarks against, the first example was “AppleCart”. He called me and informed me of the situation, and we brainstormed for a bit before Jason hit the jackpot. Appium… Selenium for Apps.
RG: Why did you switch from Python to Node.js?
DC: The language history behind Appium is long story. It was first written in python because I was just tinkering and I needed a quick prototyping language. I later converted it to C# so that it could be easily integrated with the existing web automation that we had at Zoosk. I later gave the original python source to Jason and Sauce Labs when I was trying to explain to them how it worked because they didn’t have any .NET programmers. That version was open sourced and for a few months python was the language that people were using to contribute.
RG: How did Appium get traction after that?
Jonathan Lipps and myself also spoke at a dozen or so conferences in 2013. I remember when Jonathan spoke at the Google Test Automation Conference right after we added Android support as being a huge bump. Writing the Appium Mac OS X app also gave us quite a bunch because it made Appium much simpler to use and install.
One of the funnier things I remember from the earlier days was getting a tweet from whomever runs the @bashooka twitter account, which has a very large following. It had taken us 4 or 5 months to get up to 25 or so stars on Github and the day of that tweet, our stars more than tripled in a couple of hours.
In my opinion, the thing that was most key from the get-go was answering everyone’s questions. Between Jonathan, Matt, myself, and a few others, we personally answered almost every question posted to the discussion group or github every day for the first year or so of the project. This was key. There were a lot of confusing and difficult issues with the earlier versions of Appium and had we not been so diligent with answering people, very few people would have been able to get the product working.
RG: Last year Appium 1.0 was released? What are the steps to hit the next level?
DC: You’ll get a different answer to this depending on who in the project you ask, but here’s mine. First off, there’s a lot of things that we already do with Appium that we need to do better. Installation is brutal and we lose a ton of people just trying to get the whole thing up and running. I’d like to see us do something similar to what Xamarin has done with their install and actually set up the necessary SDKs for iOS / Android if they are not already installed. I’d also like to see our Android implementation improve, and we are currently working on that by moving to newer Google Automation APIs. Id also like to see us find workarounds for the couple of things that are broken in the Apple Automation APIs (swipe since iOS7, video recording off a device, etc.)
My pie-in-the-sky vision for Appium 2.0 is that it automates all apps (desktop and mobile), and while I think it is going to be difficult, I believe it’s quite achievable. We have a working example of automating Mac OS X apps with the JSON wire protocol, but that’s largely held back due to the small Mac app developer community and the lack of OSX developers on the project. It’s possible to do for Windows Phone, but we haven’t integrated it yet due to the hefty requirement of having to have the $5,000 version of Visual Studio to use the Windows Phone Coded UI Test library. The same technique we are using for Windows phone will also work with automating Windows apps without the expensive Visual Studio version. I think I’ll take more of a look at this once Windows 10 is out so that we only have to write one version of it for both phone and desktop.
RG: Which role are you currently playing in the Appium-Universe?
DC: I spend most of my time trying to drum up interest and support by speaking at conferences and meetups and meeting with companies that work with Appium. On the code side of things, I maintain the GUI for Mac OS X and the bindings for Objective-C and (coming soon) Swift. I’m always experimenting with adding new functionality. I spent a week looking at Windows Phone last month for example. I also usually jump in whenever a new version of Xcode or iOS comes out to help solve all the things Apple will break. I’m one of a couple of people on the project that can code in Objective-C and Swift, so I usually end up filling the gaps in that space.
At the moment, I’m currently trying to improve the tapster integration with Appium. I’d like to get robot support fully functional sometime soon.
RG: Appium became a widespread open source test automation tool in mobile device clouds like Sauce Labs, Testobject, & Co. Why?
DC: There a few reasons for this. Setup of the Android and iOS SDKs can be quite difficult for people. There’s a market to take that out of the equation. iOS automation requires one machine per concurrent test you wish to run. The cost to purchase and maintain this infrastructure is something many people want to push off to someone else. Lastly, the fact that we use the same protocol as Selenium has made rolling this out quite simple as many of these providers already had existing browser in the cloud solutions.
RG: Will Selenium 3 be for mobile what “WebDriver” is for the web?
DC: I’m not sure. I don’t really keep as up to date as I probably should as to what’s going on with the Selenium project. Jonathan tends to handle that aspect of the Appium project.
RG: Regarding to a Google-Search-Graph Appium is the rising star of test automation tools. What are the USP’s of Appium making this happen?
DC: If you look at the other tools on the graph, Appium differentiates itself in three big ways. The first is that Appium provides the familiar interface of the Selenium protocol to people and we’ve found that people latch on quite strongly to that analogy. The second is that Appium let’s you choose what language you want to write your tests in. That’s a huge advantage because you appeal to all developers because you aren’t choosing the language for them. Lastly, Appium does not require app modification, so you are not excluding the group of developers that only write tests and do not write mobile applications. Appium does not require you to be a mobile app developer to use it.
In addition to all of those reasons, Appium has an absolutely rabid community behind it with over 100 contributors and over 100,000 users. Appium has a discussion group with over a hundred posts a day coming in at some times. The contributors push out several dozen changes a week and several times a month one of them is out somewhere around the world speaking at a conference trying to engage more and more people. I’ve always felt that our biggest differentiator is our community. Many open source projects are cold and unresponsive. You can submit a patch or post a question and not hear back from weeks or months. That does not happen very often with the Appium project. We’re very approachable and we don’t have any bad apples in the project that are toxic to deal with or who cause problems or conflict.
RG: Dan, thank you for this interview!