With all of the latest developments in mobile platforms and the nature of this ever changing landscape, I wanted to share my observations and opinions on how I believe testers can approach this dynamic. As part one of a three part series, I wanted to start with some initial observations and background on where we have come from.
An app is an app is an app, so mobile software testing is, at its root, just software testing. Back when I used to work with mainframes, we also tested on those; and even though there were some special considerations to be kept in mind, the fundamentals were essentially the same. Because of that, I’ll try to keep this centered on what I see as particular about mobile SQA today.
I make emphasis on “today” because one of the most apparent characteristics currently facing mobile SQA is just how fast the platforms change. Think about it. Mainframes are still somewhat popular with governments and global businesses because of their robustness, and that robustness comes directly from an almost stubborn reluctance to change. Even though technology outside of the mainframe world has changed significantly in the last decade, a lot of mainframe work during the first years of the millennium wasn’t all that different from what you would have seen back in the 70’s.
Then there’s the modern PC OS which, while getting security-patched every other day, doesn’t really see much in the way of new features until it cycles to a new version every five years or so (unless you botch it so badly that you are forced to take a mulligan).
But mobile devices are changing so rapidly that smartphones pushed their less intelligent brethren off the market almost entirely in what – half a decade? A new iPhone comes out every year, and each time they seem to put a new screen and an additional camera on them. I exaggerate of course, but I’ll present a practical example. Within the past couple of months, a problem arose because apparently Apple discontinued the location services functionality from the Windows version of Safari (which can be used to test certain web mobile application features because it shares some common architecture components with the mobile version). This is a consideration that didn’t even exist until the third generation iPhone came out in 2008 (http://en.wikipedia.org/wiki/IPhone_3G).
At its very root, mobile app testing faces the same bifurcation we saw happen with desktop apps during the last decade: native vs. web. Yes, our humble brick-sized phones have evolved into platforms that can host web browsers which in turn can host web apps. Again, as with desktop apps, mobile web and native apps present substantially different testing challenges, and I would venture to assert that multi-platform is much more easily achieved with web apps (although response across browsers seems somewhat far from consistent still). In any case, apps developed natively for iOS present an interesting characteristic: since Apple tightly controls their app store through a fairly strict certification process, native iOS apps are the first for which testing isn’t just a good idea; you must test your software in order to bring it to the market. And Apple will too.
To finish off for this first of the series and with a little bit of fun, here are a couple of assertions to think about (all answers will be provided in the final installment of this series):
True or False: As of 2012, the iOS operating system has greater market share than Android.
True or False: Angry Birds is the #1 downloaded app of all-time.
Stay tuned for next month’s installment where I’ll talk about the challenges of – “Too Many Configurations?”