Methods for Mobile App Testing Emulating Real-World Scenarios

Methods for Mobile App Testing Emulating Real-World Scenarios

If you’re a mobile app tester, you know that testing mobile apps is complicated. There’s a long checklist to keep track of, like considering the effects of various OS versions, design requirements on various device sizes, comparing the differences between Android and iOS – the list goes on and on.

Most companies have a scalable testing strategy, however, I’ve noticed a very important shortcoming that is often left forgotten – the environment in which we test. Mobile testers think testing is coherent simply by matching the test cases and installing a fresh app for each case, however, we are forgetting how the app would be used in everyday life. In my experience, nothing is more valuable than taking the time to go outside and use the app as a user would.

To make sure your app can handle anything in a real-world use case, there are quite a few questions you should be asking yourself while testing. Questions like ‘What is going to happen to the state of the app if the user gets a phone call?’, and ‘What if the user accidentally left the app open on the map screen overnight?’ are just the tip of the iceberg. To ensure that your application can truly handle any real-life scenarios, your team must start with goals and a purpose to track.

Read on for effective methods I make sure to highlight in my QA testing sessions:

Network Connection

What happens to the app when the network connection is compromised? Test cases to try:

  • Turn off Wi-Fi
  • Have the device only run on LTE/3G/4G
  • No Wi-Fi and no network connection
  • Location Services Disabled

Disruptions

What happens to the state of the app when it is interrupted by other applications? Disruptions to try:

  • Receiving phone calls
  • Receiving text message
  • Receiving push notifications from other apps
  • Facebook messenger sticky on Android
  • Alarm Clock / Full-screen interruptions
  • Open Siri/Bixby/Google Assistance/Mobile Device’s virtual assistant

Overnight testing

What happens to the app when the user forgets to turn it off? Test cases to try:

  • Put device to sleep and reopen the app
  • Background app, open another app, then reopen your app
  • Leave device untouched for (especially for things where the app uses a camera or map)
  • 10 minutes
  • 1 hour
  • Overnight

Biometrics

What if the user is using biometrics on the app? If an app requires biometrics for accessing secure data, ensure to test the following:

  • Touch ID
  • Face ID
  • Toggle biometrics on and off, see how the app handles it
  • Test on a device that does not have biometrics
  • Attempt to access data with invalid biometrics, find the limit to how many times a user can get it wrong

Testing these everyday scenarios is crucial to prevent bugs from making their way to your users. Go on a walk with your testing. Literally. Take your testing outside, you might be surprised by scenarios that were missed in development. These methods for mobile app testing will ensure that your application can handle anything that real-world users throw at it. Leave us a comment and share what you think!

Reach out to us if you’d like to talk about how we can help enable your QA and development strategies to test mobile apps faster and more efficiently.

 

Jay Soumphont

Jay Soumphont

Jay Soumphontphakdy is a Cross-Platform Mobile App developer who enjoys working in a transdisciplinary manner— collaborating and wearing hats between roles for design, development, and QA. He is dedicated to continuing his education to create high-quality user-friendly applications, recently becoming an ICAgile Certified Professional in Agile Testing and Test Automation.

3 Reasons to Update Your Workforce’s Technology

3 Reasons to Update Your Workforce’s Technology

Your workforce’s process is structured, efficient, and tested, but over the past few years, your workforce’s technology may have become outdated. Change can be terrifying, especially when changing an established process.

You’re probably asking yourself, “Is the upgrade worth it?”

We’d like to help you answer that question. Here are top three reasons why an upgrade to your workforce technology should be your priority for 2018:

1. Intuitiveness. Today’s recruits — your new employees — live on their mobile devices. The outdated user experience of older devices may be a hassle for newer recruits to learn. Providing familiar experiences via mobile solutions may speed up training time and productivity.

2. Mobility. If your supervisors currently only have a desktop solution, it may be time to mobilize them. By converting to a mobile solution, your supervisors will be able to spend more time with their team on the floor and reduce their paper trail by using a mobile digital device. Mobility also includes freeing up the hands of employees who handle products, which may allow minimizing steps in a process’ workflow.

3. Credibility. When showcasing your warehouse or workforce to clients, having up-to-date technology would demonstrate the high-tech baseline of your company. Clients want to know that their product is being handled with the utmost care. Stay competitive by removing chaotic manual processes and motivating the workforce with mobile technology. Apps create a better customer experience, which in turn leads to repeat business and long-term revenue growth.

Case Study: Arrow Electronics

In 2015, Shockoe began to develop mobile solutions for Arrow Electronics’ Warehouse Management System (WMS). Arrow’s core mission is to be “five years out”; they strive to incorporate new technologies and electronics to become innovators of the tangible future. They service over 125,000 original equipment manufacturers, contract manufacturers in over 90 countries/465 locations. Arrow looked to build a strategy to extend its WMS into Mobile Solutions to increase productivity in its distribution centers and beyond.

Improvements Arrow saw by upgrading their tech:

  1. Intuitiveness. We replaced warehouse operators’ bulky 7-pound RFID Scanners with lightweight, handheld Bluetooth scanners that can be carried throughout the warehouse and kept in constant connection with their devices. In the upcoming phases, we plan to have the operators be completely hands-free via wearable technology. By exercising our knowledge in the latest user experience research, we were able to bring their processes to color and implement a simple color language for operators to more efficiently understand their app. We also translated supervisor data into easily consumable graphics that allow for easy sorting and customization.
  2. Mobility. Supervisors are no longer tied to their desks; they can now walk along the floor with full access to their data. Within the apps for the supervisor and operator, we implemented a communication tool to allow for easy messaging and scheduling. When an issue arises, operators can easily message their supervisors and supervisors can walk over to resolve issues.
  3. Credibility. By upgrading to bleeding edge technology, Arrow is living up to their mission to be five years out. They are setting themselves up as an ideal example for mobile warehouse solutions.

Deciding to upgrade?

Whether it’s your clients or your workforce, people love when you step up their experience. Ensure user satisfaction throughout the process by developing a schedule for introducing the upgrade, creating a training plan, and introducing a system reevaluation process to minimize the need for larger upgrades down the line.

Here at Shockoe, our team has aided multiple clients with mobilizing their workforce’s technology through mobile apps, Bluetooth technology, and hands-free technology. From rough sketches on paper to launching the final product, we maintain an intimate relationship with our clients to guarantee that their workforce is content and comfortable with changes to their processes. Check out our awesome case studies for upgrading technology:  Arrow, ONEOK, A.C. Moore, and J.B. Hunt.

Note from Editor: 

If you’re interested in learning more about our engagement with Arrow, you can watch the full Case Study interview here!

 

3 Ways to Improve User Engagement on Your Mobile Solution

3 Ways to Improve User Engagement on Your Mobile Solution

After months of development, your app finally makes it onto the app store. However, a few weeks later, you take a look at the app’s analytics to find an unexpectedly high number of total uninstalls.

Why are users deleting your app and what can you do to improve user engagement?

1. Improve User Onboarding
A crucial, often overlooked process in designing an app is the user onboarding process. User onboarding is essentially the method in which the app introduces itself to a new user. Within the first few minutes of use, your app should make a solid first impression.

Resolution:
– Start the app off with a friendly tour to get the user acquainted with the main features
– Highlight features one at a time – do not overwhelm your user with introductions to all of the features at once
– Place mission critical information upfront and concisely
– Place user values upfront – You want the user to envision how they will be using your app in their day to day life as soon as possible.

Below are a few examples on user onboarding on Winn Dixie. Our UX and UI designers put great care into the onboarding strategy– putting the designs through various critiques and presentations with the client. User Onboarding testing was implemented as early as wireframes.

Winn Dixie app Iphone iOS

Winn Dixie grocery app

Winn Dixie App Grocery

2. Reduce Clicks
Ideally, a user wants to use the least amount of clicks to get to the information they want. Information or features buried into tabs and menus may infuriate users trying to accomplish a simple task. Sometimes the cost of effort may not be worth the payoff for a user.

Resolution:
To resolve these pains, consider bringing in various testers as early as the design phase. Sometimes paper prototypes can be very telling of a user’s engagement of an app based off something as simple as an app’s layout. Reduce the amount of effort a user has to make by designing the method of navigation with well-defined paths.

3. Debug your app

On first glance through reviews of a low rated app, the number one issue reported by users is: the app is buggy and keeps crashing. The bane to any user on any software is one that they can not use properly. Buggy apps can be caused by a multitude of occurrences. Here are the top three reasons why your app may be buggy and bugging your customers away:
– Android or iOS hardware and software have updated causing your app to be out of date
– Uncaught memory leaks
– Weak user testing

Late last year to in anticipation for the release of iOS 10, the Shockoe development team thoroughly prepared by catching up on documentation and thumbing through depreciated features. Apps like 21st Century were given an update to ensure that the app would not be out of date. Changes included improvements to security and touch ups on depreciated UI features.

Resolution:
Test the app thoroughly to find as many bugs as possible and prepare another cycle of development! At the end of development, put the app through another round of testing to ensure that your app is functioning as ideally as possible.

Positive user engagement is essential to maintaining users. While the suggested improvements drive to enhance user experience on your app, be prepared to take note and study of how these methods impact user interaction. Taking a closer look into what propels users to continue to use your app or what you find users interacting the most within your app will greatly help you analyze and improve positive points in your mobile solution.

Want to stay connected on all things mobile?

Sign up for the Shockoe newsletter and we'll keep you updated with the latest blogs, podcasts, and events focused on emerging mobile trends.

Getting Innovative with Bluetooth Scanners

Getting Innovative with Bluetooth Scanners

At Shockoe, we are given the opportunity to work on innovative projects that push to incorporate the latest technologies. Upon entering Shockoe, my first assignment was to develop a native module to allow bluetooth barcode scanners to pair and interact with an android device via the app. As this was my first time jumping into both titanium and java, I was thoroughly confused on how to accomplish my assignment.

 

Through scavenging together documentation and filtering through previous projects, I somehow got the job done. For those of you who may be new to titanium and modules, here are some useful tips and broken down concepts that I used to make module development easier.

 

Creating a shell script for building and packaging your module

*Primarily for CLI users

 

If you’ve done module development before, you know it can be a chore to integrate your module into your titanium project. You have to build the module, delete it from your titanium project if it is already installed, uncompress the module into your project and install it locally.

 

Having to do this process over and over while testing a module can take up an unbelievable chuck of your development time. Luckily for me, my co-worker Eric, a developer who I was collaborating with to create the module, came up with the idea to use a shell script to build our module and integrate it into the titanium project for us.

 

Here is an example of the script:

bluetoothmodule.sh

#!/bin/sh
 

#Remove the current module from the project folder
rm -r ~/Files/Projects/BlueToothFolder/BluetoothDemo/modules/android/com.shockoe.bluetoothModuleDemo

#Navigate to the module project folder
cd ~/Files/Projects/BlueToothFolder/modules/bluetoothModuleDemo/android

#Clean the folder
ant clean

#Run ant to build the project
ant
 

#Unzip the created folder
cd dist/
unzip -o com.shockoe.bluetoothModuleDemo-1.0.0.zip

#Move the unzipped folder into the Titanium folder
cd modules/android

mv com.shockoe.bluetoothModuleDemo/ ~/Files/Projects/BlueToothFolder/BluetoothDemo/modules/android

#Alert when finish and return back to the project folder

echo "Finished"

cd ~/Files/Projects/BlueToothFolder/BluetoothDemo/ 

#Build the project to your connected device

appc run -p android -T device

This script saved me countless hours of having to re-build and install my tests while developing the module. Feel free to use it and edit it to your needs!

 

Exposing Methods

To allow your titanium project to access methods in your module, you can expose methods through the @Kroll.method annotation.

A simple example:

bluetoothModuleDemoModule.java

@Kroll.method
public String returnstring(String testString){
	return testString;
}

Then in your index.js:

index.js

// Require the module into your controller
// This particular module is Android only
if(OS_ANDROID){
	var blueToothDemo = require('com.shockoe.bluetoothModuleDemo');
}
console.log(blueToothDemo.returnstring(‘Hello World!’));

And as expected, ‘Hello World’ is printed to our console.

 

Here is a simple example that I used in the bluetooth module:

bluetoothModuleDemoModule.java

// Expose the method
@Kroll.method
public void enableBluetooth(){
	// Determine if bluetooth is enabled or not on the device
	if(!bluetoothAdapter.isEnabled()){
		// If bluetooth is not enabled, enable it now
		bluetoothAdapter.enable();
		Log.d(TAG, "Bluetooth Enabled”);
	}		
}

Now in our controller we will be able to directly call the enableBluetooth function:

index.js

// Call the enableBlutooth function in the module
blueToothDemo.enableBluetooth();

 

Firing Events

Just like how you can trigger events in Javascript, you can trigger events in the module’s Proxy through its built-in event management with fireEvent and hasListeners.

A simple example:

bluetoothModuleDemoModule.java

// Some method that gets called to fire a string after it is given data
private void exampeFire(String data){
	if(data == null)
	return;
		
	this.fireEvent("sendData", data);
}

In your controller, you would receive the data listen for the data like this:

index.js

// Listen for emitter from the bluetooth module
blueToothDemo.addEventListener(‘sendData’, obtainedData);

function obtainedData(data){
	console.log(‘received the following data: ‘ + data);
}

In a larger concept, this is how I used fireEvent within the bluetooth module:

bluetoothModuleDemoModule.java

// Using the BroadcastReceiver for registering when a bluetooth device is found.
    private final BroadcastReceiver myReceiver = new BroadcastReceiver() {
        @Override
        public void onReceive(Context context, Intent intent) {
            Message msg = Message.obtain();
            String action = intent.getAction();
            
            if(BluetoothDevice.ACTION_FOUND.equals(action)){

            	bluetoothDevice        = intent.getParcelableExtra(BluetoothDevice.EXTRA_DEVICE);
            	BluetoothClass blclass = intent.getParcelableExtra(BluetoothDevice.EXTRA_CLASS);
            	
            	int Majorclass = blclass.getMajorDeviceClass();
            	int minorclass = blclass.getDeviceClass();
            	
            	
                deviceList = new KrollDict();
                
                try{
                	deviceList.put("name",bluetoothDevice.getName());
                	deviceList.put("macAddress",bluetoothDevice.getAddress());
                	deviceList.put("pairedStatus",bluetoothDevice.getBondState());
                }
                catch (Exception e) {
                    Log.w(TAG, "devicesFound exception: "+e.getMessage());
                    postError(e.getMessage());
                }

                devicesFound();
                
            } 
        
        }
    };	

// Fire the event with our deviceList to our titanium project
private void devicesFound(){    	
    	this.fireEvent("devicesFound", deviceList);     			
}

And just like in the simple example, we will listen for the event in our controller:

index.js

// Listen for emitter from the bluetooth module
blueToothDemo.addEventListener(‘devicesFound’, devicesFound);

var devicesFound = function(e){
	console.log(e.name);
}

Our deviceList from the module’s devicesFound method will be represented by e. If all went well, then console.log(e.name) should print the bluetooth device’s name into our logs!

Exposing methods and firing events was the bulk of the information that I needed to comprehend to get started on my bluetooth module. Hopefully this helps a titanium and module novice get their start on their project as well.

 

Small Tips

  • If you’re new to modules, I would play around with Appcelerator’s ti.moddevguide on github. To reach the module code, follow the path in the src folder. To see how the module can be implemented into a titanium project, check out example/navigator.js.
  • Find or develop a native method of what you would like your module to do and break it down to be usable in a module. Determine what methods to expose and where events need to be fired
  • Read Appcelerator’s Module Architecture Guide. The docs do an excellent job at detailing the various ways to expose methods and handle properties.
  • Specifically for bluetooth, read Android’s developers guide for bluetooth development