We all make software that works beautifully, but how many put a high priority on making software with a beautiful look?
All our testing efforts are concentrated on functional enhancements and corrections so as to make the product work better. But how many of us really think about making it look better? Probably, in our terminology, beautiful software is software that is bug free and stable. But what does the end user understand and expect in terms of beautiful software?
For me, software is beautiful when it works effortlessly with the person sitting at the terminal. And the program has an appearance defect if something that you reasonably expect to appear is missing, awkward, or confusing. The user should find it painless and fun to use the software. Effective onscreen instructions, adequate information, and interactive dialogs can make the software look and function better.
Testers may argue here that they already perform usability testing on every application that is driven with a user interface. If you get a little deeper into the concept, you will see how Usability and Beauty are two independent and yet inseparable entities. Usability is all about the ease, speed, and pleasantness with which the user can use the application. And during usability testing, ease and speed are still given importance, but pleasantness often remains in question. If the “pleasantness factor” is well taken care of, we will certainly succeed in creating beautiful software with high-end functionality. Beauty actually serves toward acquiring better usability.
The major drawback of a technically competent team developing and testing software is that the look of the software often takes a back seat to functional mechanics. Perhaps that is because everyone on the team is so preoccupied with proving their technical skills and making the product tech-rich that they tend to forget the comforts and ease of the intended user. But paying a small amount of attention to the application’s serviceability toward the user can dramatically improve the software’s quality and the user’s overall productivity.
Nine out of the ten applications that I get to test are not really good-looking. To be more blunt, these applications are downright ugly. Now, don’t mistake them for being technically poor. They are rich with features. But they can be awarded, at max, two points on a scale of ten for their visual merits. When it comes to captions, font color and styles, meaningful and appropriate dialog boxes and error messages, I often feel like redoing the whole thing. For such products, my bug list actually starts with appearance and communication issues.
In my personal experience, developers love to ignore such issues. “It’s not a bug as long as the window has some caption,” they are apt to say. “Throwing an error dialog in there is enough. Users at least get to know there is something wrong with their input.” Developers suggest that I keep these types of issues in my bug list as lower priority ones. “If time permits,” they say, “we may think of looking into those. After all, the application runs fine without them.” This attitude on the part of developers probably discourages testers from reporting cosmetic bugs. Testers may feel reluctant, fearing that they might be misunderstanding the functionality or reporting “trivial” bugs. But I always practice and preach that a tester should approach the developer with every issue that pinches him. It’s never offending to clarify doubts. What if you are actually seeing something that makes the developer take note? Maybe it was not ignorance on the developer’s part but a mistake that he would like to rectify. It is even better if the tester succeeds in convincing the developer that these issues are targeted toward reducing the software’s complexity.
I also encourage testers to dedicate some parts of their testing to nontechnical exercises. Testers are generally very comfortable writing functional test cases. But did any of us ever think of designing special test cases to catch appearance defects? Probably not. Minor defects in looks are mostly taken for granted in our trade. It’s misguided to believe that while performing functional testing, any look-oriented defect will be easily caught. If you have a small test case or even a checklist handy, you will realize what an amazing result it shows. For decent enough software, my appearance test cases are as small as half a page. But they cover some important issues like uniform looks, effective user communication, color combination, window placements, meaningful captions, tool tips, etc.
At least once during the testing process, you need to take off the tester’s hat and put on the user’s hat. Only then will you be able to understand how a small appearance issue may trouble a user. We don’t realize the effect of such deficiencies probably because we know their technical simplicity. But for a user, the front-end information carries more value than the back-end processing. For this reason, I always prefer a nontechnical tester in the test group. No one can track appearance problems better. As an alternative, you may have one efficient tester dedicated for such testing while others concentrate on functional testing. For large projects, you may even consider “scenario-based testing,” which is a very effective method of usability testing. For those who find this term unfamiliar, such testing involves presenting the application with the expected set of real-life usage patterns with the application. It is recommended to measure the human-computer-interaction characteristics of the system.
A tester’s primary concern is finding bugs, but that’s not the only job. Suggesting better alternatives is something a tester should try every now and then. Try suggesting better and more meaningful captions, better color schemes, and whatever else may make the product look appealing. When you cannot suggest corrections, think of enhancements. The nice thing about such enhancements is that—unlike the application construction where things have to be perfect at the first chance or you will never get a chance again—aesthetic enhancements can be introduced any time during the project lifecycle with very little risk. Most of the time, such efforts involve very few lines of code change but their effect will be drastic and marvelous.
Beauty can be beautifully confusing, as different users have different expectations. What looks beautiful to the tester may look nonappealing to the developer and ugly to the user. You can’t anticipate everyone’s expectations, and even if you could, you probably can’t satisfy everyone’s need without losing the program’s integrity. I suggest that aesthetic issues should be dealt with by a representative group (mostly testers, developers, and users) formulated by knowledgeable experts in consultation with system designers, experimenting on a separate copy of the application, and then finalized. Such representative groups are more productive because the group forms a consensus about aesthetic issues, which is better than a one-on-one debate between a tester and a developer.
So next time you are testing software, along with finding defects in the existing stuff, keep an eye out for things that can look better. All of us, who used to stay satisfied with usability testing, might add beauty testing to our schedules. And let the user feel as happy using the software as we do testing it.
