Mobile applications continue to multiply as every week thousands of mobile applications are uploaded onto the Internet for end users who download to various types of mobile devices and operating systems. We want to try to save time and effort and automate where we can but as with any test automation, the first consideration is what should and what should not be automated, or can/cannot be automated. What parts should remain for manual testing? Automation should be used judiciously in the right places. Here are a few places that are best left to manual testing.

Where to Use Manual Testing (and not use Automated Testing)

  • Negative testing

Negative testing scenarios are quite difficult to design. Even if designed, most often it is not worth it to spend much time on developing scripts because it may not be executed frequently.

  • Testing device-specific features used in an application i.e. Camera, accelerometer, GPS & Bluetooth

Specific device features are sometimes not accessible by automation tools because APIs are packaged and scenarios are quite difficult to simulate by codes. Manual testing is more applicable here.

  • Compatibility between applications like Call & SMS interrupts

Automation tools have difficulty simulating these interrupts. It also is difficult to run or execute two different applications at the same time using automation tools.

  • Voice-mail or IVR based scenarios

Automation tools are not good at predictive intelligence. None of these tools can send nor verify the voice, like identifying is someone is talking or checking if there is any break. The conversation between the testing scripts and the phones is difficult to implement unless you know exact scenarios and convert them to binary codes. In this case, it’s better to use manual tests.

For more information on using mobile automation download the free White Paper.