The beauty of Internet-enabled applications is that it's easy to add value with rich media, real-time monitoring, and other features. But with this flexibility comes new responsibilities for testing the "goodness" of applications in real-time situations. For instance, if employees are using mobile devices powered by Internet, app developers can no longer assume a stable in-office environment in which their applications will be used. Instead, they might have to consider whether an app will be used in a moving car, or in temperatures below freezing. This conflicts with present IT application testing methodology, which usually doesn't go far enough to test for environmentals and usability. As a result, IT can miss the boat in its testing strategy and find itself doing much more work in app maintenance.
Here are 10 things to consider if you are developing apps that have to function with outside "things," —environments and usability challenges that you can't readily foresee in your test lab.
1: Think about how people will use the application
An application that comes packaged on a consumer-grade laptop or notebook for a police squad car will not withstand the rigors of high-speed chases and constant bangs and knocks. Part of the application testing strategy, if you are developing for situations like this, should include the testing of the robustness of the device itself in adverse operating conditions. If you fail to include the device in your test plan, the app might be great — but it might also crash at a critical moment if the end device fails.
2: Consider environmental conditions
It doesn't do anyone any good if an end user tries to place a consumer-grade device in a freezer to monitor temperatures. Ruggedized handheld devices are especially designed for work in extreme cold conditions. This is a case where it is important to know the environments that users are going to use their mobile devices in — which again, makes it essential to include the device as well as the app in your test plan.
3: Develop a comprehensive test plan with a checklist for usability as well as for app features and functions
Eighty percent of end user acceptance of an app comes down to usability (over features and functions). Yet interestingly, an IT test plan is usually the reverse (80 percent features/functions and 20 percent usability). I once redesigned an app that had been sitting on the shelf at a company for more than two years because it had an unfriendly user interface. Once we pared away two-thirds of the interface (and reduced the features-functions set to make the app less complex), the uptake by users was almost immediate.
4: Actively engage users in testing
Engaging users in testing (especially for usability and fit for environment) ensures that there are no surprises from the user side when the app goes into production. It also ensures user signoff and buy-in for the app and an ongoing collaborative relationship with the end business unit as you enhance the app over time.
5: Engage users up front in app design
Many IT application developers now get users involved at the very beginning of application design, especially when it comes to designing the application interface. It's a good practice, because it provides a working blueprint of user interface requirements that your test plan can be linked into. It also puts the users (and not IT) in charge of designing the "look" of the app.
As soon as developers have a working model of an app, they should sit down with end users and demonstrate both the user interface and how data flows into and out of the interface. These demo sessions should be short and iterative (as more pieces of the app are completed), and they should occur often. Doing this will ensure that the app continues to track true to user requirements. These regular prototype reviews will significantly shorten QA and final test times.
7: Build scalability into your app — and test for it
Especially for Internet and mobile devices, app add-ons such as rich media should be anticipated to grow. Your design plan should anticipate this (e.g., scalability for storage, CPU, bandwidth) — and your test plan should test for it. By sizing for future expansion, you can avoid costly app redesign.
8: Include security and lockdown
Data encryption, conformance with security standards, and locate and lockdown ability when devices get lost are all important test points for mobile devices. IT usually gets the first two, but the locate and lockdown is often missed. It shouldn't be. Thirty billion dollars worth of mobile devices were lost last year.
9: Use standard APIs for app interfaces
One of the worst nightmares for application integration (and almost all apps are integrated with various data repositories, other apps, etc.) is the development of custom interfaces that have to be changed over time — and which in turn create maintenance work on every other app they touch. You can save a lot of time in regression testing by sticking with standard APIs.
10: Make testing everybody's business
We've already talked about getting end users engaged in final checkout and in intermediate checkouts. But it's also good to include input (and checkout) from the help desk, which understands as well as anyone in IT what the constant user pain points are. It's also a good idea to split your QA team into two camps: one side that tests the app for technical "goodness" and a second side that tests for usability and overall "fit" for the business and the end user's work environment.
Mary E. Shacklett is president of Transworld Data, a technology research and market development firm. Prior to founding the company, Mary was Senior Vice President of Marketing and Technology at TCCU, Inc., a financial services firm; Vice President of Product Research and Software Development for Summit Information Systems, a computer software company; and Vice President of Strategic Planning and Technology at FSI International, a multinational manufacturing company in the semiconductor industry. Mary is a keynote speaker and has more than 1,000 articles, research studies, and technology publications in print.