Porting – Continuous Testing and DevOps Blog

We all know that the mobile world is dynamic, plenty of new handsets are being shipped at the same time in which we develop our product and testing on the (what we believe) is the “hottest” handsets in the market.

It is clear that being agile and fast in the way we develop, test and deploy our mobile products is a key to be attractive in the market, however it is also impossible to support all handsets and be ahead of the market.

So – The way to be up to date in the offering, is not simple but possible.

When you start developing your product keep in mind that by picking the “right” 10 handsets which are “hot” in the market you can reach the coverage of ~50% of the market (Note that there are lead devices which represent a whole family of handsets and can give you a lot of value by testing on it), as well if you go to ~30 devices you may reach up to ~80% coverage of the market.

How should you decide than?

The way to do the picking of handsets should combine the 2 following aspects:

– Market research

– Right family identification/lead devices

Market Research: The way to determine what is relevant in the market is to do some research and analysis – either through leading mobile blogs, or even simple – going through the leading mobile operators in the world, and seeing what they are currently selling (e.g. Vodafone global lists today in the top list of devices in Germany: Samsung Galaxy SIII, Samsung Galaxy SII, SEMC Xperia Arc S etc. – http://shop.vodafone.de/Shop/smartphones/, if you go to Vodafone UK you will see mostly the same ones, as well as HTC One X and others http://www.vodafone.co.uk/brands/android/index.htm)

Doing a matrix and unification of handsets between the world leading carriers in Europe/U.S/Asia should give you the lead handsets which you would like to support and test in the 3-6 months ahead (Per OS – Android, iOS, Windows Phone and BlackBerry).

Families: The aspect of family should be a subset of the above list If e.g you reached a common list of lets say 50 handsets, i am mostly certain that the list can be cut into half by doing proper comparison between the various handsets by their OS, Screen resolution and OEM (This can be done through sites like GSM Arena – http://www.gsmarena.com) and minimizing the list by leads, members and families.

Please find attached to the post an up to date list of common handsets by OEM which is sold world wide these days to ease your pain 🙂 –> As you will see, there are a lot of similar handsets across all large operators which can show the main devices to focos on.

MobileWorldHandsetsDistribution

P.S: With regards to the leading Android/iOS tablets these days:

iOS – iPad 2 and iPad 3

Android – Samsung Galaxy Tab 10.1, Motorola Xoom, Asus Nexus 7, Dell Streak 7, Samsung Galaxy Tab 7, Sony Tablet S. Asus Transformer TF300, Asus Transformer TF700

Regards,

Eran

When we talk about mobile world complexities, it is important to understand the meaning of Porting.

We know that the mobile platform is dynamic, often changes and being influenced by many aspects (Calls, SMS’s and other interrupts, but also from diversity of mobile OS’s, new devices entering the market and more)

Porting of mobile apps, means – To take an existing working mobile application (Game, utility, web service or other) which was proved to work fine on few “lead”/”gold” devices which were (hopefully) well-defined by the project manager, and make a port of the application to many other handsets, tablets and so on.

You can imagine, that any generic core bug in one of the “lead” devices will obviously drill down to the ported handsets, so at first it is important to pick the right “lead” device which is new enough in the market, solid, and represent a “family” of existing devices (e.g. Samsung Galaxy SII for the Android OS).

Second thing to keep in mind, is that the time to develop and release a product (Mobile related) is ~3-6 months so the device needs to still be “relevant” in the market and be considered a “lead” in the market at the time of release.

Once we are certain that we picked the right lead devices and we have a Beta version with all features implemented and functioning, we than enter the porting phase in which we start to introduce new devices (hopefully from the same families of the lead devices which we ported) and install the application on them to perform sanity.

If the application was developed and designed “for portability” – we should be able to produce various version per new handsets which are built from the same core base with the distinguish of icons, resources and minor differences – in that case fixing bugs should also be easy.

If the design was not right than we can enter a “nightmare” of fixing bugs backwards in the core source, and maintaining many old and new devices for a long time.

The right model is to have a solid and generic core source base from which the release manager generates using build targets the right handsets by using property files which matches the right device “family” and profile.

Porting bugs can vary between handsets and can be caused by many reasons which are not always related to our application (e.g – an application which uses GPS or Camera and these functions are buggy on the device may impact the application stability – this is something which porting should handle, issues related to screen resolution, rotating from landscape to portrait and more).

In our days when we have the Android OS, iOS and Windows Phone and we wish to develop similar application to these 3 or more platforms, porting becomes even more complex – For that we can consider the above insights, and also integrate tools such as Code Name One, PhoneGap or other tools which allows to use one code base and deploy it to various mobile platforms and languages.

In future blogs i will try and refer to the method of developing a master test plan for the lead devices and a subset/sanity test plan for the ported devices which are derived from the lead ones.

For questions and more details, you may contact me as usual: eran.kinsbrunner@gmail.com