User:Vital Kumar Uppuluri

Mobile application platforms like Android, iOS, Blackberry etc. are now trendy things. The market for mobile application is growing everyday and the demand for this applications are rising as the technology is advancing. Most of the general software testing principles apply equally well for mobile application -- in a general overview -- but in my small experience I have found some cases and curious questions where it differs! There is a huge variety in mobile application technology, platform, devices and they have their own complexity while developing. So while testing - this "extra' complexities needs to be handled. We can spot out some specific areas of mobile application testing where extra care for testing is required. 1) Technology specific testing: All of the technologies has their own properties as well as own pros-cons. While testing mobile apps testers needs to be more careful and conscious about the technology pros-cons.

2) Platform specific testing: Each and every platform for mobile apps has its own properties. And the nature and behavior of the platforms and the apps at the top of it conveys them. Testers need to be concerned about these issues while testing.

3.) Device specific testing: My little experience on developing J2ME applications tells me that even if an app runs on emulator quite smoothly - unlike desktop apps, it may not suit all the J2ME supported devices -- even if the version and Api versions are all same. That enables quite a big consciousness while testing a mobile app.

Now if we like to create a list of things to be considered specially while testing mobile applications -- we can create a list which also covers up the basic things we do while testing a mobile app.

First, Functional Testing. As per definition - this testing will cover up testing the basic functionality of the app. In fact, the procedure starts right from the application store (like iTunes for iOS, android store, etc.) because the quality of the app will depend on if it comes to users with ease or downloads seamlessly. Now techniques for functional testing may vary in two ways: first is testing the app using a simulator (most of the case it is called emulators) and the second is testing the app where it will be used i.e. on device. In ideal case, both of the approach should be followed. Because, if some of the feature of the app like clicking on a button or link works on emulator but not on the device -- that should be a device specific fault. Additionally, the running environment (sdk version, api version, etc.) for the app in emulator and the device should be same or at least similar. Like in regular SQA process, this testing should be started at the very beginning of development cause changing in app design or architecture costs a lot.

Secondly, Usability Testing. To the best of my understanding it is the single most critical testing for mobile applications. Mobile devices are of a HUGE variety. Screen size, scrolling buttons, joy-stick, trackballs, touch screen inputs, folding, sliding and many more. Now for the same app, user experience and easiness differs hugely based on these things. Like in a form with 7/8 inputs can cost 4 clicks to a user of Nokia 2700 phone while it is just a smooth slide to a Nokia 5800 owner (Leaving alone the iPhones and androids :S). And first impression of user while using a mobile app creates the future market scope for the app. And who doesn't know that only word-of-mouth of bad experience can be broad-casted to the market and hence can destroy the business of the app. That is why usability testing of an app is the critical most step in testing.

Thirdly, Performance Testing. Here comes another point in related to app in addition with device specific test and that is performance of the network carrier. If the network carrier is stable enough and the device is a smooth performer on the carrier - risks of crashing the application minimizes to a great deal - specially for the apps which requires data or call transfers. Another issue is region or location. Performance of carriers may vary location to locations. If the performance of the app is poor to end-users they are meant to be diverted to other similar apps. In most of the cases, performance of the app is likely to be measured with the help of tools cause it is very hard to create a real life "load scenario' in front of the testers.

Finally, Selecting Testing Methodology. In our organization, mobile apps are being tested in-house with the development team in front of the PM with client's direct feedback. This method has both pros and cons - it is a controlled process i.e. it is not very much tough to create the diverse test environment with different types of devices with different carriers and under use-case scenarios of the dev team. But the fact is it is too much expensive (in accordance to time-money and resources). Among the other methods can be testing with simulators/emulators -- but as I mentioned earlier they doesn't give you the 100% real UX scenario. There can be community testing or beta testing, that is releasing the app within a limited community and they use it with limited features (or may be full) and report problems found. This is more effective than others but is time consuming and not all the areas can be covered (naturally) cause the users in a community is of more or less similar type. My observation here is -- the methodology should be chosen with respect to the nature, volume, budget and of course its device-carrier requirements. A hybrid of all the methodologies can be a good solution for medium level app.