About ten years ago I was testing the installation package for a Windows application. The installer was a standard one, similar to what we are all used to: a set of screens through which most users will usually click Next, Next, Next to install the software.
As long as I was using the mouse, everything was fine. But because I prefer to use the keyboard whenever possible, I tried to install without using a mouse. It turned out that even though the focus on each screen was on the Next button, hitting Enter did not activate the control.
I opened a bug report. I even quoted Microsoft’s forms controls documentation:
“On any Windows Form, you can designate a Button control to be the accept button, also known as the default button. Whenever the user presses the ENTER key, the default button is clicked regardless of which other control on the form has the focus.”
It turned out that I am not the only one who can quote Microsoft. The developer dealing with my bug report responded in kind:
“The spacebar activates the control with input focus, whereas the Enter key activates the default button.”
If you think about it, you can see that the developer was right. On the other hand, I argued, the user expects Enter to work because this is how most other installers work. I was advocating that our program be consistent with the market, despite this implementation being technically incorrect.
Eventually I convinced the development manager that consistency is important enough to justify the fix and that it trumps the Microsoft documentation.
It is easy to agree that consistency is important when discussing the user interface or the way in which a product implements actions that are closely related (for example, having the program use the same file-explorer interface when using Save As and Open). But I think there are other parts of a software product where being consistent is just as important, even though they are not as visible as the user interface. Additionally, I see consistency as one of the product aspects that we, as testers, have a responsibility to check.
Here are some areas where consistency is important but is frequently overlooked.
System interfaces—especially those that are exposed externally, such as the system’s published APIs—are a fertile area for consistency bugs.
If the application offers a rich API, it is almost guaranteed that the code for these APIs was written by a number of developers. Each developer has a somewhat different style and a different way of thinking about what is convenient, self-evident, and easy to use. This impacts the function names, the input and output variable names, and the order in which they appear in the function call. The result is that the consistency of the API package is degraded.
On top of this you will find simple mistakes that are the result of the developers knowing their code so well that they don’t notice when some small detail can mislead a person who encounters the API for the first time.