IN THIS CHAPTER
Software is written to be used. That sounds pretty obvious, but it's sometimes forgotten in the rush to design, develop, and test a complex product. So much time and effort is spent on the technology aspects of writing the code that the development team ignores the most important aspect of softwarethat someone will eventually use the stuff. It really doesn't matter whether the software is embedded in a microwave oven, a telephone switching station, or an Internet stock trading website. Eventually the bits and bytes bubble up to where a live person will interact with it. Usability is how appropriate, functional, and effective that interaction is. You may have heard the term ergonomics, the science of designing everyday things so that they're easy and functional to use. An ergonomist's main concern is in achieving usability. Now, you're not going to get the knowledge of a four-year ergonomics degree in the 15 or so pages of this chapter, nor do you need to. Remember from Chapter 1, "Software Testing Background," the fifth rule of what constitutes a bug: The software is difficult to understand, hard to use, slow, orin the software tester's eyeswill be viewed by the end user as just plain not right. That's your blank check for usability testing. You're likely the first person, other than the programmers, to use the software. You've become familiar with the specification and investigated who the customers will be. If you have problems using the software while you're testing it, odds are the customers will, too. Because there are so many different types of software, it's impossible to go into detail about usability issues for all of them. Usability of a nuclear reactor shutdown sequence is pretty different from usability of a voicemail menu system. What you'll learn in this chapter are the basics of what to look forwith a bias toward software that you use on your PC every day. You can then take those ideas and apply them to whatever software you have to test. Highlights of this chapter include
|