Issue 4, 2013 |
Download pdf |
The closing stages of application development can be an intense period, when developers are often up against strict deadlines to complete the project. But once coding is complete, don’t rush into deploying your mobile app without first adequately testing it.
On-device testing
One of the most important tasks to factor into mobile application development is on-device testing. It’s all too easy during development to become complacent with the tools on your desktop and forget to actually try out an application on a real device. Hardware developers provide accurate and fully featured emulators within their software development kits and webMethods Mobile Designer also includes an incredibly fast and convenient device simulator. While these tools are often indispensable to programmers, they should not be relied upon to give a 100 percent re-creation of the real world.
Testing on physical hardware is the only true way to see how an application will really perform. The performance of a desktop emulator will never truly match that of an actual device and certainly can’t predict what might happen when a device’s processor is under heavy load (e.g., when running several apps simultaneously). Other seemingly simple situations, such as being interrupted by a call or text message, can only really be tested on real hardware.
On-device testing is by no means a simple task. It’s easy enough for developers to install a working version of their application on an iPhone® (for example) for testing. In reality developers should have access to many different models. Apple® currently supports 11 different types of iPhone and iPad®, and a developer may wish to support earlier models still. Add to this the fact that a user may be running one of several versions of the operating system and/or firmware and things can quickly become complicated and expensive.
Developing with webMethods Mobile Designer does provide reassurance that apps will function well on a wide variety of devices. Plus, using the native UI libraries will increase the chance of an application working well across the wide variety of devices and platforms. However, installing applications on actual devices for testing is never a bad thing.
User testing
Programmers and designers will often spend so much time with their applications during development that they become too closely involved to think objectively about how well they have implemented their solution. This is where user testing is invaluable. Collecting feedback from real users who are new to an application is an ideal way to uncover flaws and issues that might otherwise be ignored.
User testing does not have to be a massive undertaking. In his article “Why You Only Need to Test with 5 Users,” Jakob Nielsen, one of the world’s foremost experts on software usability, explains that testing an app with as few as three to five users may be sufficient enough to get valuable results. Read more of Nielsen’s article here.
I certainly think that testing an app with more than one person is essential. Otherwise, there is a risk that abnormal results might not be detected (e.g., the first tester might already be an expert in a particular field, or maybe are just lucky with their first interaction). But testing with a very large group of people will probably just increase cost while simply serving to provide duplicate results.
Ideally, a small group of users should be asked to repeat their user testing after the developers have made attempts to fix any problems highlighted in the first round of testing. This iterative approach may continue for two or three rounds and is the best way to yield effective results.
Organizing user testing can be as simple as observing a group of colleagues using the app for the first time, although it is likely that a developer would want to be more formal in both preparation and execution. Online services such as uTest and UserTesting are relatively inexpensive and can help free developers from having to find test candidates.
App store submission
Another important stage in the development of a mobile application is deployment. If an application is being delivered via a private network such as Software AG’s webMethods Mobile Administrator then this task is easily managed as the developer is in total control. However, if developers plan to deploy their applications via one of the online marketplaces, such as Apple’s App Store or Google® Play, then some control is relinquished and this comes with associated risks.
Apple will reject applications that are faulty, so testing is vital to ensure this simple hold-up is not encountered. And even if an app is approved, it takes time before it becomes available. Traditionally, Apple App Store approval could take anywhere between one to four weeks. Fortunately, the approval process wait time has been reduced dramatically and currently averages around one week.
Online marketplace submission and approval is not as simple as just uploading your latest build. There will be a varying amount of supporting material required, ranging from icons and screenshots to product details and customer support information. Developers would be wise to set aside time to be thoroughly familiar with the process before embarking on it for the first time.
Conclusion
These examples certainly don’t cover every case, and there are many tasks that will arise at the end of a product’s development cycle. Localization is another good example, as ideally it is better to translate copy in bulk rather than in small stages. It is common for this to happen near the end of project, once all the text is finalized. However, developers should consider the possible impact of long text strings on their user interface design when creating applications in multiple languages!
webMethods Mobile Designer and the entire webMethods Mobile Suite as a whole will certainly help smooth the journey for mobile app developers, but there is no substitute for planning ahead.