With smartphones and tablets becoming the new enterprise endpoint, mobile application testing should move up the list of priorities for IT managers. The lessons we have collectively learned from dealing with Windows updates apply just as much for mobile devices. A strong update strategy involves rigorous testing, closely managing the update process, and ensuring excellent situational awareness and communications. Let’s dive into how to account for each of these requirements.
Testing
If you are writing your own applications, you should already have a strong test plan, but when you are using someone else’s application, you still need to have a way to test the application in your particular environment. This is generally called “black box” testing, because you don’t have the source code. With black box testing, your goal is to gain confidence that the application is going to work properly by applying a set of end-to-end tests.
Testing may be second nature for developers, but for IT managers it can be a bit foreign, and one that might seem like someone else’s job. To some extent that’s true; it’s not your job to be sure that an application works correctly in every case or to debug problems for the application vendor. But mobile applications don’t exist in a vacuum — they have an entire ecosystem around them, and that’s what needs to be tested. Plus, if things stop working, users don’t want to hear that it’s someone else’s fault.
Protect your company from IoT cyberattacks
White Paper
Watch this free webinar on managing employee IoT devices using Samsung Knox and Zero Trust. Download Now
The best way to avoid outages is with a little proactive testing whenever the ecosystem changes: application updates, system or firmware patches, and operating system upgrades. Designing these tests can be a challenge, but the best way to tackle the job is to keep three important concepts in mind: persona, scope and coverage.
Persona
Persona is the type of user and the things they do. Software developers sometimes associate this with a conceptual “journey.” The idea is to pick a particular task and write a test that covers the entire process a user would go through. Different users have different tasks, and your testing should cover the most common tasks for each type of user. You’ll want to consider the different user types and their varying journeys through multiple applications and operating system functions as you decide what to test.
Scope
Next, consider scope. How much software, including applications and operating system functions, do you need to examine? For example, authentication is important to test, so you’ll want to write a test with a scope that covers authentication. But don’t stop there. List out all the key functions that overlap with the app you are testing, and write tests that cover the spectrum without overlapping too much.
Coverage
Scope goes hand in hand with coverage. Coverage is how much of the application and ecosystem you’re actually testing. Your goal is 100 percent coverage: You want to say that you’ve tested everything that the various personas will use to get their jobs done. By considering the scope of each test, you may find it easier to get your coverage up to 100 percent.
With a little bit of thinking about your types of users and how they use applications, you should be able to get a small set of tests written to cover a large portion of the applications and operating system functions that your personas use. You’re not trying to duplicate the entire quality assurance process, but you do want to make a solid and honest effort to be sure that any updates can be checked in the lab before you roll them out to early adopters.
Of course, you can use automated tools for this. Do a search for “black box android application testing” to find some good candidates, such Google’s Android-specific Espresso, UI Automator and Monkey testing tools.
Manage updates
All this talk about testing assumes that IT is in control of when updates for applications and operating systems are applied. In fact, without careful management of the whole update process, there is no opportunity for testing — end users will download application updates and operating system updates at random, and there will be no hope of having a predictable and dependable application environment.
Android devices control application and operating system updates separately, so you’ll need to manage both processes in order to ensure that updates of all types are delivered properly.
For application updates, your mobile device management (MDM), enterprise mobility management (EMM) or unified endpoint management (UEM) tool can take over from the normal Google Play Store by controlling which versions of applications are delivered to each device.
If your overall environment is mature and stable, you should only have to focus on the applications that are part of your enterprise portfolio — it is unlikely that the latest update to Pokémon Go is going to break your enterprise resource planning (ERP) application. However, this is a place where multiple Android Enterprise profiles can help mitigate risk by isolating enterprise applications from personal ones.
You’ll also have to control operating system updates. MDM tools may provide some control over these updates, though they are usually handled quite separately from application updates. In addition, device vendors may have more specialized tools available. For example, Samsung Knox Enterprise Firmware Over The Air (E-FOTA) is a Knox Suite tool specific to Samsung Android devices that provides granular control over operating system and firmware updates, including scheduling and forcing deployments without user interaction.
Best practices around controlling updates include blocking application and operating system updates until there’s been an opportunity to test them and delivering these updates to test groups in a controlled way before rolling them out across the enterprise. It’s also important to have a rollback plan in case a showstopper rears its ugly head, even after testing has been completed. IT managers need complete control over and visibility into updates to make space for testing and ensure that changes are deployed in a way that doesn’t impact productivity.
Situational awareness and communications
IT managers know there’s a thin line between too much and too little communication about software updates. If you tell end users that something has changed, problems may start popping up — even if they have nothing to do with the changes. Testing and managing updates are key tasks, but an equally significant part of the process is ensuring that problem reports are promptly investigated and assigned appropriate levels of importance.
When a problem report comes in from an end user, support teams must quickly determine which versions of software are on the mobile device without asking the end user and establish whether any ongoing software update campaigns are part of the problem.
The MDM is the primary dashboard that should deliver information on the status of applications and operating systems to support teams. That means if these groups don’t already have access to the MDM, now is the time to get them connected or build links between MDM tools and other help desk and software/hardware inventory systems.
Mobile devices are a fast-moving and changing target, so application and operating system updates and upgrades should be more frequent and more important than updates in mature desktop environments. IT managers can avoid end-user productivity hiccups by taking control of updates, executing a well-designed test plan and ensuring that any problems that do show up are triaged quickly and thoroughly.
Learn how to build a cyber incident response plan in our free white paper, and get to know the whole Knox Suite of mobility management solutions.
