Robust QA is an integral part of mobile/embedded software development. Mobile QA can, at times, be quite daunting even for experienced embedded professionals especially given the permutations and combinations of devices, carriers, features, platforms, content, security, performance and much more. Though we can dedicate a complete book to write about the best practices on mobile QA, let me try to highlight a few key areas that should be covered:

Mantra: Nimble process, Domain specific coverage!
1. Device Capabilities: The QA team needs to understand device features really well. If the application needs to be tested on various devices, it is virtually impossible to keep track of device feature sets unless the team has a feature/model/platform matrix that is used as a reference for developing test cases. The most common mistake I have seen across apps is inability of QA/Dev teams to gauge device display resolution and relate the display related nuances to assets/resources of their applications. SD Card and dependency on storage is another one.
2. Platform Interaction: Lets put it in layman’s terms. Device send signals to the Operating System (platform) which sends signals to the runtime (virtual platform) which sends signals to your application. Further, access to device/platform resources is governed by policies set by/on the platform. If you don’t understand this, writing test cases around interaction with OS/Runtime is virtually impossible. Memory management is wrongly considered to be an in-process imperative by a large number of QA professionals, another common mistake that requires early attention. It is important to understand bidirectional communication between your app and the platform and via platform with other apps. Get this and your architectural thought process will improve, hence better QA around Platform Interaction
3. Network Interaction: A number of platforms put policies/set restrictions on how you access network resources (edge/3G/wifi), concurrency around network connections and at times the data formats that are allowed. If you don’t understand how your app communicates over transports with your servers (beyond the device) and how your app feature set is dependent on this communication, you will certainly have a few ugly hiccups related to performance, no data access and/or your app being blocked from distribution channels. QA team needs to account for these scenarios. Again, understanding of this imperative and comprehension of these scenarios is the key before good test cases can be written around these.
4. Application Features: Functional testing. What else can I say? If you don’t understand the primary, secondary and tertiary features of your application. Your test coverage will always be below par. Usability, User Experience, Screens, Data, Ads, Metering … all of it is part of app features. Get the features right, you will get the functional test cases right. The most common mistake: What to do when a feature misbehaves? Simple: Graceful recovery or alternate scenario.
5. Location of Consumer: If you cannot think like a consumer, your app will misbehave in the New York Subway, In London Tube, Under water, Around Tall buildings, near bad vibes and during the demos. On a serious note: Understand the usage scenarios from consumer’s perspective.
6. Service Provider: Plan for edge, make the experience rich on 3G, even better on 4G and the best on Wifi. Understanding data formats and how they behave across these carrier network access levels is the key to writing great test cases around service provider scenarios. Another one is carrier policies: data limits, usage plans, internet tethering policies, get your provider matrix ready. By the AT&T’s network is ….. than Verizon …. than Sprint …. to I left it at my mommy’s place is not a valid excuse for a good QA team.
I can go on and on and give 100s of examples around these scenarios. My take on QA is simple:
a). Understand the domain (write test cases that are domain aware)
b). Keep the processes nimble
c). Automate last (imagine having automated tests running in a huge environment covering 5% of the functionality)
Tune in for more ….