It doesn’t matter what sort of application you’re creating—every application requires testing by an appropriate audience. Even VBA applications, such as those described in VBA for Dummies, require testing. I wrote about this topic in C# Design and Development, but it applies to all developers equally. The application stakeholders need to be involved in every phase of application development, but most especially in the testing phase. You may obtain stellar results when testing your application using a select group of users, but the real world is much harsher. Users come in all shapes and sizes and your application must accommodate them all.
One of the most critical groups to include in your testing environment are those with special needs. I wrote about this group in Accessibility for Everybody: Understanding the Section 508 Accessibility Requirements. It’s important to understand that our aging population makes testing for this group critical. I think that Microsoft’s statistics are low, but you can read about how Microsoft has improved the accessibility features in Windows 8 in Enabling Accessibility to accommodate all groups, especially the elderly. However, you also need to include less skilled users, those with a lot of skills, but little computer knowledge, and those who are quite technically savvy, but want to get their work done quickly. In short, your stakeholders should include someone from each group of users in your organization. (The smart development team creates a list of these groups before the application is underway in order to start obtaining input from them as early as possible.)
Someone recently wrote me to say that he applauds my efforts to encourage developers to write better applications. The reader went on to say that I didn’t have any idea of just how hard the real world could be though and that actually implementing even a subset of my ideas would be incredibly hard. In short, the idea of accommodating everyone who will use an application is simply not possible in today’s environment. The problem with this attitude is that not accommodating user needs actually ends up costing an organization more in the long run.
It’s essential to understand that applications can be well-written and yet not serve the needs of the people using them. You can create a fabulous application that no one uses quite easily. When I say that testing must involved appropriate application testers, it means that these testers must represent all groups who will actually use the application and that you must accept all sorts of input from these users. The input may require that you rework the user interface or that you fix certain bugs. In some cases, you may even need to remove features because the stakeholders will never use it and the feature simply ends up confusing everyone. Applications that don’t address the needs of the users will cost your organization time and money in the following ways.
- Users have a choice about applications today and they will simply ignore your application to use something that meets their needs better.
- Whenever users become confused, they call support, which ends up costing your company both time and money.
- Support calls take time and your user isn’t being productive while talking with support.
- Even when the user is able to use the application, the accumulation of errors tends to slow the user down and increase the time required to perform a task.
- Confused users tend to try combinations of things in frustration, which often results in data loss and other unfortunate consequences.
Part of the problem with the corporate atmosphere today is that management applies considerable pressure to get an application in production as quickly as possible. A developer can become quite tempted to use a group of “yes man” testers to show management that the application is ready for use, when it really isn’t even close. The theory is that it’s much easier to ask forgiveness for a poor design later, than to ask for additional time today. However, savvy developers know that it’s easier to change an application design than to apply fixes to an application that’s already hosted on a production system. The bottom line is that you always need to test with the appropriate group and create an application that really will do the job.
What are your worst experiences with application testing environments? How do you choose the testers you rely on to check your applications? Let me know at John@JohnMuellerBooks.com.
In my book, C# Design and Development, I discuss the need to consider the application environment in a number of places. For example, on page 106 you’ll find a discussion of the corporate environment on the requirements for application speed. A discussion on page 431 describes the need to achieve application goals while treading softly on the user’s environmental settings. Application environment can include a lot of different considerations. That’s the reason the ComputerWorld article entitled, “‘Consumerization of IT’ taking its toll on IT managers” struck a cord with me today. IT is now faced with a situation where users rely on personal devices more often than corporate-supplied devices, which is wreaking havoc in many ways.
The article will enlighten you about the woes that IT faces. What the article doesn’t describe are the woes that the developer faces. When an application developer creates a new application for the corporate environment or provides changes to an existing application, the testing process must consider the devices that the application will run on. When the developer works with a known set of corporate-supplied devices, the testing process is predictable. However, when the developer must also consider personal devices, the testing process is more like the environment for shrink-wrapped software, which means that the developer must now consider an open environment in which the user could rely on any device. In fact, developers must consider the following application design, development, and testing issues as a minimum due to consumerization.
Security: Early corporate applications didn’t come with much security at all. As government regulations, data breaches, and other issues have come to light, developers have added security to application, but not at the level of shrink-wrapped software and certainly not enough to ensure protection of corporate data.
Reliability: Every device that accesses an application has different characteristics. These characteristics determine how the device interacts with the application. Adding devices increases the number of potential interaction types and reduces overall application reliability due to issues with non-compliant devices. Obviously, testing can no longer have even a hope of finding every application interaction issue, so developer will need to create a robust application error handling mechanism with the organization.
Presentation: As device types increase, so do the presentation environments that the application must service. It isn’t just the fact that these devices will have different sized screens, but also the need to address audio and input characteristics of a wide range of devices. A developer must now consider how best to define an application interface so it works with the broadest range of devices possible.
Multiplatform Considerations: A development staff may begin designing an application to work on a particular platform, such as Windows, only to find that users also want the application to work on Android or the iOS. Even when the user sticks with desktop or tablet devices, the application may need to support Linux or OS X. In short, the development staff needs to consider multiple platforms when creating an application today. Unfortunately, Web-based applications aren’t always the best choice—leaving the development staff with some tough decisions to make.
There are other considerations to make, but you get the idea. Today’s development environment has become extremely complex due to consumerization. Unless your organization has firm policies about personal device usage in place and actually acts on those policies, you need to consider the idea that the user could access your application using just about any device on the market today. You have a number of ways to deal with this situation, including the following suggestions:
- Create a list of tested configurations so that users know which devices are most likely to work with the application.
- Make users part of the initial design process so that you hear about needed device support as early as possible.
- Track new device releases because many users will get the latest gadget and expect it to work with your application.
- Define a specific procedure for adding new devices to the application support list so that you don’t have to deal with user requests in a confused manner.
- Keep an open mind because users will work with personal devices whether you support them or not.
This whole issue of consumerization could easily consume a chapter or more in a book. What have your experiences been with consumerization? Is the new application development environment becoming impossible to manage? Let me know your thoughts at John@JohnMuellerBooks.com.