As we've discussed in some of our other articles, testing your mobile application before sending it to market is important to its overall success. The testing phase is where any user experience (UX), coding, text, or graphics issues can be found early—and therefore fixed—before your app's released to the general public. While it's true that no one's perfect, testing gets your app as close to perfect as it can be. And that's what you want your potential customers to see.
Whether you have two or two dozen testers for an application, it works better for everyone involved to have a testing process that's consistent and guarantees the best possible accuracy. Before the testing can even begin, however, you have to take in mind how it's distributed to your testers. You want them to have the exact same information and the exact same version of the app prototype, so everyone begins on the same page.
It's interesting, then, that many app developers use what's called “ad hoc” app distribution in order to send prototypes to their testers. The term's Latin translation—literally “for this”—implies a specificity that in practice often really doesn't exist. Ad hoc distribution and testing in practice is itself a fairly vague process, and for that reason there are inherent flaws that can come up as early as the distribution phase.
There are several different ways app prototypes can be distributed in the ad hoc testing model. They can be uploaded onto a shared drive, emailed, or shared online via cloud computing, to name just a few examples. On top of this, many different methods of distribution are used to test the same app; this can result in confusion and chaos from the start. Not only do you run the risk of slightly different versions of the app being sent out, but there could be issues with downloading the apps to different devices, as well. Additionally, if cloud computing is used, there's an added risk of having your app's information falling into the hands of outside parties. In our humble but educated opinion, ad hoc distribution and testing carries the potential of becoming a disorganized mess in a hurry.
The installation process for ad hoc builds also varies significantly between the iOS and Android operating systems. For instance, most newer Android devices have management software which comes with the device, or it can downloaded from the maker. This software enables you to download and install apps directly to the device without going through the apps store. You can also install an Android app directly onto the phone after downloading it from an email, once you've changed the device settings to allow installation of non-store apps.
Apple devices are a different case entirely. Each Apple device comes with a unique identifier, commonly referred to as a UDID. This identifier is a string of 40 alphanumeric characters, and Apple verifies this identifier when you download apps from the store. Unless you've jail-broken your device (not recommended for many reasons, but that's outside the scope of this article) you can't just install apps to the phone like you can with Android.
Therein lies the challenge for iOS developers: it's important to test the app throughout the build cycle, and the above-mentioned ad hoc distribution methods add to the challenge of getting a build to a user to test, and the user being able to manage the installation of the test build. One of the main hurdles is the UDID of the test device; if it's not added to the build, the app won't install. The UDID challenge can be an article all its own, and we'll return to that subject soon where space allows.
So, how do we overcome the obstacles in sending out iOS builds ?
We've given ad hoc distribution and testing a try, and in our experience we've found a better and more consistent method that we now use when distributing all the iOS apps we create to our testers. By using QR codes—those square “bar codes” that can hold much more information than regular UPC bar codes—we can instantly and consistently distribute app prototypes and testing instructions to all our testers easily and quickly.
We use an over-the-air system that automatically validates the UDID of the target device, without us having to know it prior to delivery, and by scanning the QR code from the device (or clicking an emailed link on the device) the build automatically downloads and installs directly.
So now testers don't have to deal with multiple downloads, or incorrect versions; the QR codes allow for instant loading onto their test devices. Everyone gets the exact same app, with the correct code and everything. The code goes only to our testers, and has a 72-hour time limit for installation before the code expires, so this drastically reduces the chance of it accidentally getting to outside parties.
Most importantly, we've listened to our clients, partners and testers, and they've enthusiastically endorsed the QR code method of app prototype distribution. Gone is the confusion, fighting with downloads, all the unnecessary hassle in general. Everyone on board knows exactly what is expected, and we've found it has streamlined our testing process greatly.
Not a member? Get started today! You can post comments here and join in the discussion over at out forums.
Login or Register