It is said that by 2015 there will be 1.6 billion mobile devices connected to the internet (according to Morgan Stanley). According to Verizon that number will be 20 billion by 2050. That’s 5 times the estimated mid-century population of the planet.

What the research doesn’t tell us is how many variants there are going to be of those devices. As with the entire history of computing we have always had to face the challenge of supporting old platforms and future platforms.

In the world of testing for mobile devices we are also facing many new variants introduced because of the capabilities of the different networks (phone and surf works on AT&T but not on Verizon for example), the regulations on data capture that vary from state to state and country to country, support for national characteristics of language, character set and even culturally sensitive color schemes. Form factors change from platform to platform with buttons, screen size and resolution a never ending evolutionary imperative. In some countries support for users with disabilities are mandated. In other countries some capabilities need to be turned off. The possible number of configurations needed to be supported runs to the 10’s of thousands and is increasing exponentially each time a new platform is introduced. Or hybrid platform like the newly announced Kindle Fire.

So what do tools look like that support the testing of all this diversity?

Configuration management is a critical piece of this puzzle. A configuration management tool that can maintain the configurations across a number of intersecting vectors of Operating System, Hardware Platform, Country Regulations, State Regulations etc. Perhaps the most important attribute to maintain though is risk: what risk is non-compliance? Is it loss of revenue or time on jail? Is it having your platform banned in that country (Samsung Germany). Is it massive fines for your corporation?

Automated testing tools are also critical to enabling adequate test coverage of the mobile application. Investment in this area is often far below where it should be. In terms of relative complexity mobile apps tend to focus on the mainstream actions (compare your online banking experience through the web site to on your mobile banking application). This means that the number of variations of test paths is more controlled.

Remember that each time the UI changes it invalidates the automated tests. So the mobile application needs to be architected for testing. Segment the functionality so that features that are not changing are unaffected by changes to parts of the application that are. This prolongs the currency of the automated test scripts.

And finally ensure that every action is logged and tracked so that reports can be run and “hot spots” determined and fixed over time.