In mobile application testing, details are everything. It’s easy to default to mobile OS emulation, but that isn’t quite the same as figuring out what you missed on an actual device. For example, I was texting a blind date one time to say, “I’m dying to finally meet you!” I shifted my hand and sent “I’m dying” by accident. After a brief moment of alarm, I had to explain what happened. Guess where the send button was on my 3rd party keyboard application? Right next to my backspace button. Too bad my date didn’t turn out well either. 1) Don’t just emulate, rotate! This one seems like a no-brainer, but you’d be surprised at how many developers forget about testing device reorientation from portrait to landscape. There’s no other way to reliably test it unless you’ve got a device in your hand. Emulators just don’t cut it. You also don’t know what kinds of gymnastics your users are doing with their phones. I even tested an application that crashed in iOS if the phone was turned upside down. Not good. 2) Carrier barriers and restless leg syndrome. It’s called a “mobile” device for a reason. Humans are notoriously squirmy and are always running around with their devices in their hands. What happens when they leave the WiFi perimeter? This isn’t something you can easily mimic on an emulator. Your emulator, as sparkly as it is, also can’t test the real world effect of different carriers such as Verizon or Sprint. It matters. Test out your application with a real world device that uses that carrier’s SIM card. 3) Application interruptus. We’ve all played Candy Crush on our phones, and then mom calls to ask when you’re coming home for the holidays, even though you’ve already told her three times. How will your application respond when your user pulls it back up? The same issue goes with texts, Twitter, and Facebook notifications. What happens then? 4) Swipe right. A lot. Every device is a unique snowflake, just like you. How will specific phone models and OSs react to real-life haptic commands? We’ve all fat-fingered our phones. Ever accidentally order 10 pizzas instead of one because of a slip of a finger? Oops. (I ate them all anyway.) 5) Is your application a power vampire? In the legendary words of Forrest Gump: “Cell phone batteries are like a box of chocolates. You never know how long they’ll last.” Okay, maybe he didn’t actually say that. But you know what we mean. Testing battery usage with an application is a critical part of mobile application testing. Battery drain is a constant hassle for anyone with a mobile device, especially when running specific applications (we’re looking at you, Facebook). Make sure your application doesn’t feast on a device’s battery. You can do this via the OS’s battery stats or by using 3rd party software. Some phones, in this metaphorical box of chocolates, already come with notoriously short battery lives. If you want to be even more thorough, all you need to do is Google battery life complaints per mobile device. Then you can plan accordingly. 6) Where in the world are you? People travel. A lot. If your application does location checking, you’ve got to make sure it keeps up with your user’s device location. This also applies to NFC. If your application is proximity-based, that’s definitely something you’ll need a physical device to test with. 7) Pest control. Don’t forget, emulators are software too! Just like everyone has their quirks, OS emulators have their own set of bugs. There are emulator bugs that don’t see the light of day on a real device and can’t be replicated in the real world. Why waste your time on unnecessary bug hunting? Most of these tips seem like common sense, but we’re just looking out for you. Do you have any physical device testing tips or experiences you’d like to share? Give us a shout in the comment section!