One challenge for any IT project is to ensure that testing is performed efficiently and effectively. As with many things the goal is to try to find a happy balance. In this case ensuring quality without spending forever on the testing cycle. Before I go any further my intention here is not to dwell on V charts, and testing frameworks but rather to talk specifically about testing enterprise mobile applications.
- Graphical User Interface (GUI)
- Screen flow/workflows
- Mobile device/s
GUI, Screens, & Integration
Certainly a lot of the focus when testing enterprise mobility should be the application, its screens, and integration. Involving end users early (when managed correctly) can really help to ensure that the screen flows work under real use scenarios. Often functions can be tested independently during the development cycle. Device Emulators/simulators on a desktop can help rapidly test while waiting for the infrastructure and comms to be put in place. If the mobile application works in an offline way then ensure to test for data conflicts, locks, and test the resolution process. How can the solution recover from an integration error?
An important consideration that is sometimes overlooked is the wide variety of Mobile devices, models, operating systems, screen sizes, peripherals, and input methods that are being used in the solution. Don’t assume that everything that works on Model X will automatically work on Model Y.
Battery life – does your shiny new mobile application drain the battery flat in minutes? Is it using lots of CPU when decompressing or encrypting data? Does it constantly require communications or gps? Schedule some tests to simulate different levels of usage.
Communications (or lack there of) should be checked. What happens when halfway through a transaction the comms is lost. What happens if comms is slow or poor? I’ve seen some creative ways to test this. For example underground car parks, driving through dead spots, or using a Faraday chamber. When projects first move from simulators to devices they are often cradled or connected via Wi-fi. Ensure at some point to factor in tests based on real world communication scenarios.
With infrastructure it’s often not possible to directly replicate the production environment. However it’s definitely worth looking at simulating traffic. Try running functional tests while ramping up the load and find out at what point problems occur. MEAPs often come with tools for capturing, simulating, and amplifying traffic.
Authentication & Security
Its obviously important to test the authentication and security mechanisms. Consider carefully how the authentication works and schedule appropriate testing. What happens when passwords expire or the user enters it wrong too many times. Some companies hire in specialists to attempt to compromise the system.
As part of the overall strategy consider using a technical go-live where the mobile application is put into production and tested without being used for real business. This may require assistance from the business to run through some transactions and then back them out. Once the technical solution is confirmed then one or two key users can be introduced to the solution. At this stage monitor the system thoroughly and adapt any changes as necessary. Once proven expand the user base gradually and ensure that performance is managed. On some projects it’s necessary to initially throttle the performance so that the first user group does not feel negatively impacted once the entire community is live.
Please let me know your thoughts and any addtional lessons learnt from testing enterprise mobile applications…