You Are Not Done Yet: Input Methods

You are not done testing yet unless...you have tested the following input methods:

• Keyboard. Duh, right? But it's important to remember that testing keyboard input doesn't just mean verifying you can type into text boxes. Scour your application for every different control that accepts text - not just as a value, but also shortcut key sequences and navigation. (Yes, there's some overlap here with Dialog Box Navigation and Accessibility.) If your application uses any custom controls, pay them especial attention as they are likely to use custom keystroke processing. Make those mouse-hating keyboard wizards happy!
• Mouse. Duh again, but again it's so obvious that it's easy to miss. And again, pay especial attention custom controls as they are likely to do custom mouse handling.
• Pen input. Depending on your target platform(s), this could mean pen input direct to your application, filtered through the operating system (e.g., the Tablet Input Panel on Microsoft Windows), and/or filtered through third-party input panels. Each input source has its own quirks that just might collide with your application's own quirks.
• Speech input. Depending on your target platform(s), this could mean speech input direct to your application, filtered through the operating system, and/or filtered through third-party speech processors.
• Foreign language input. On Microsoft Windows this usually means an Input Method Editor (IME), either the one that comes with the operating system or one provided by a third party. These can be troublesome even for applications that do not do any custom keystroke processing. For example, a Japanese-language input processor likely traps all keystrokes, combines multiple keystrokes into a single Japanese character, and then sends that single character on to the application. Shortcut key sequences should bypass this extra layer of processing, but oftentimes they don't. (Note: turning off the IME is one solution to this quandary, but it is almost never the right answer!)
• Assistive input devices such as puff tubes. The operating system generally abstracts these into a standard keyboard or mouse, but they may introduce unusual conditions your application needs to handle, such as extra-long waits between keystrokes.
• Random other input sources. For example, I have seen games where you control the action by placing one or more sensors on your finger(s) and then thinking what you want the program to do. Some of these devices simply show up as a joystick or mouse. What happens if someone tries to use such a device in your application?
• Multiple keyboards and/or mice. Microsoft Windows supports multiple mice and keyboards simultaneously. You only ever get a single insertion point and mouse pointer, so you don't have to figure out how to handle multiple input streams. You may, however, need to deal with large jumps in e.g., mouse coordinates. Oh the testing fun!

Posted by The Braidy Tester at 07:30 AM  Permalink