Technical solution architecture

Solution architect • 2014-15

In 2012/13 Appium was a newly emerging mobile app testing framework. Mobile app testers can use it to run test scripts on their local machine to test mobile apps running on real mobile devices. Appium was gaining traction since it could run same tests on both Android and iOS apps. A cherry on top was the flexibility in writing scripts in any preferred language including Java, Js, Python, Ruby etc.

 

OVERVIEW

Architecting and implementing a solution to integrate Appium test framework as a Cloud service.

BRIEF

Research, architect and create a Proof-of-Concept solution to offer Appium test framework on Bitbar’s cloud as a SaaS offering.

ROLE

Solution architect

METHODS

* Proof-of-Concept engineering
* Reverse engineering hacking / development

RESULTS

* Bitbar was acquired by SmartBear in 2019, and Appium was one of company’s main offering.
* Successfully closed pilot customers including Disney, Salesforce, Lyft, Fitbit and more.

 

How can a mobile tester test apps on all the versatile devices in the world?

State of technology

Appium was a newly emerging mobile app testing framework. Mobile app testers can use it to test mobile apps running on real mobile devices.

Appium was gaining traction since it could run same tests on both Android and iOS apps. A cherry on top was the flexibility in writing scripts in any preferred language including Java, Js, Python, Ruby etc.

Mobile app testers can use Appium to test mobile apps running on real mobile
devices, connected directly to their machine. Additionally, the tests could be run on one device at a time.

 

Bitbar cloud

Bitbar’s business was to source every possible unique mobile device from around the world and put them to Bitbar Cloud, for customers to run tests on.

Goal

My goal, in simple terms, was to make Appium test originate on a QA engineer’s machine but run on any mobile device of choice connected to Bitbar Cloud.

 

Solution Architecture

My solution was to architect and implement the ‘Broker’ concept. A middle-man software that handles the communication between test-scripts running locally on user’s machines, and real Android / iOS devices connected to Bitbar Cloud

 

Before / After

Even on highly technical project, my secondary focus was in providing an easy to use product. Although the audience of the product was exclusively technical users, we still strived in making it as simple as we can.

One example was the persistence to use device name, instead of the unique device ID. It was difficult to implement, but easier for the user to get what he wants.

 

Key results

 

 

Technical details

 
Appium broker architecture • 2013
Appium broker architecture • 2013

first evolution

Running test-scripts live from user’s machine had it’s pros and cons. To tackle the cons, we introduced uploading the scripts to the cloud, and running them on the same machine the mobile device is connected to. This gave user the choice between two different ways of executing tests.

The two original ways to run Appium @ Bitbar Cloud
The two original ways to run Appium @ Bitbar Cloud

post acquisition

Bitbar was acquired by SmartBear in 2019. A reincarnation of the above diagram is now found on SmartBear’s support page

Appium at SmartBear
Appium at SmartBear
 

Keeping the UX in mind

Even on highly technical project, my secondary focus was in providing an easy to use product. Although the audience of the product was exclusively technical users, we still strived in making it as simple as we can.

One example was the persistence to use device name, instead of the unique device ID. It was difficult to implement, but easier for the user to get what he wants.

Group.png

The easiset would’ve been to implement an ID system like “1235454”. But that’s an extra step for the user to first get the ID from the info page, and then use it.

 
 

Previous
Previous

product framework

Next
Next

bird. android app