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.