Over the last decade the most significant change in software testing has been the growth and advancement of automated testing. In the past, web site testing was costly and time-consuming. You had large teams of QA Engineers that hunted the site for bugs during test passes. These engineers had to run hundreds of test cases in a few days against multiple browsers. Code was usually frozen during the test pass and developers could either fix bugs or had to work on another branch or product. By the end of it all the QA engineers were bleary-eyed and sweating as the release went out.
Enter Automation, which reduced test time by allowing developers to automate test cases and run them on demand. This more frequent and more immediate feedback enabled them to write better code and freed up QA engineers to test with more freedom.
Then mobile came along, and we were back to square one. Years later, the first mobile automation tools were developed and released. These early tools all had major drawbacks. They all required you to modify your application to support testing, usually by embedding an HTTP server in your app. Most of them only supported coding in their APIs, which rarely supported multiple languages. They also were doing things that were hacks or workarounds and not sanctioned by the guys making the OS.
Appium was originally developed at Zoosk back in late 2011 when we were looking to reduce the cost of testing our iOS app. iOS testing presents a throwback sort-of challenge which harkens back to the days when software was released on disks and CDs. A mistake in an iOS release will take days to correct. If you have a crash, once you figure it out and fix it, there’s a multi-day app-store approval process on the other end. It’s different than the web because you can’t just do another deploy and fix the problem; you must suffer the consequences for days even with an expedited review.
There are 4 principles that guide Appium development
- Test the same app you put in the marketplace.
- Write tests in the language you want to.
- Use a standard automation specification
- Keep it open-source and free
Principles aside, what is Appium? Appium is an implementation of the Selenium-WebDriver Protocol (the most popular web automation toolset) that supports controlling Android and iOS applications on devices and simulators. Coding an Appium test is identical to coding a Selenium test. You don’t have to modify your application and can use a protocol that is a (pending) W3C standard. Selenium already has bindings in a dozen or so languages, so you can even use the language of your choice. Under the hood, it uses the sanctioned automation APIs, UIAutomation for iOS and UIAutomation and Instrumentation for Android. And of course, it’s all open source.
In closing, the future is here. Mobile automation is now as easy as web automation. Your mobile QA team can blister their fingers playing guitar instead of by performing 3 straight days of iPad test passes. You can submit your app to the app-store faster and with more confidence.