QA Engineers, Learn About Design
I was on vacation in the mountains of Colorado. We were staying at a small cabin near the Conejos river. The simple A-frame, 2 bedroom cabin was built by my wife’s relatives in the late 1970s. As you would expect from a good cabin, it is supplied with old stuff from various sources. The magazines have not been updated in years. There is a small TV with a built-in VCR and a few Disney movies on VHS. The lighting consists of chandeliers purchased used from the Golden Corral restaurant. There are no two pieces of silverware that are the same. The septic system provides constant nourishment to a slightly taller patch of grass about 50 feet from the front door. Despite its size, it can somehow accommodate 75 people for a family party—as long as 65 of those people are in motion. It is, for all intents and purposes, a classic old cabin.
On the morning when it was our turn to make breakfast, I took it upon myself to cook bacon. I got out the warped frying pan, stripped of any of the original teflon by time and neglect, and placed it on the electric harvest gold stove. I turned the heat to medium and began to cook bacon. Anyone who has cooked bacon knows that if the pan gets too hot the grease starts to crackle and pop— burning any exposed skin and spewing grease on anything you are wearing. As I was unfamiliar with this stove and crappy pan, I got the pan too hot. I turned it down and kept cooking. Still spattering, I turned it down more, and more, and more. The more I turned it down, the more the grease popped and spattered burning my hands and arms. Finally, in a moment of baffling frustration, I looked more closely at the worn knob for the burner. There were numbers 3–12 indicating the temperature. There were also words under the numbers indicating the temperature. Have a look and see if you can see the problem.
The problem was that the hottest temperature is a three! I thought I was turning it down because I was moving the knob to a lower number when—in fact—I was turning it up and burning myself with molten bacon grease.
The mental model and how you remember things
You don’t remember how to work every device you come across, or all of the information required to complete every task you have to perform. This is because you don’t have to. When was the last time you learned a phone number? You don’t have to because you can remember a name much more easily, and your phone will do the mapping for you. Another example is google. How many things do you choose not to remember because you know how to look them up? You have offloaded that information from your brain to the cloud. This is a principle that good designers know and understand.
In using a device you have never used before, you go through a similar process. Visual cues, physical constraints (information stored outside your brain), and previous knowledge of similar devices all help you to use something you have never seen or used. This particular stove had numbers that were opposite of what I was expecting based on previous experience and common sense.
How does this apply to testing and software?
User experience design happens during the entire process of creating software. This happens with or without an actual designer. Let me repeat that—user experience design happens with, or without, an actual designer. Compromises, tweaks and misunderstandings creep in all along the way.
Imagine that this had been a software knob. The QA engineer tests the final product and says, “hey, developer, I think I found a bug. Don’t you think it is a bit weird that the temperature goes up as the numbers go down?”
To which the developer says: “
And for some reason (time constraints, honestly believes this is a good solution, et cetera) the QA engineer accepts this as good enough.
This is an exaggerated example to be sure. But this happens all the time in software—just put an extra button here, or make a tool-tip there, or a colored dot over there...
Hackish solutions are accepted because it is “good enough” or “easier”. Mike Monteiro said:
“Enough good enoughs taken all together are not very good at all.”
As a QA engineer, it is your job to understand and be proficient at a lot of different things: how the product works, the specifications, how to test things, how to write test cases, how to write test plans, and communication skills are among the minimum. Design and design principles are fields of study that often go overlooked by all but the designers. This is a mistake. Of all the disciplines that you can study outside of the core testing skills, design is one of the most important (design is not just how something looks). In our example above, had the QA engineer understood how the human mind works with regard to novel devices, he would have not have let the knobs with the backward numbers make it to production. Did the knob meet all the technical specs? Yes it did. It turned, it adjusted the temperature, and it looks pretty much like the prototype. It just had one tiny detail wrong that may have seemed less important. In design, it is the details—sometimes the tiniest, nuanc-y details—that make the difference between a mediocre design and a great design.
Back to our software knob
Now let’s imagine that the developer built the knob exactly to spec (has that ever happened?). The bug would then lie in the design. The QA engineer, with a sound understanding of design principles, would be able to detect the bug, report it, and have it fixed. The developer will whine because he built it to spec, which is true.
In this case, the spec was wrong.
As a QA engineer, you are in a unique position to view the product as a whole. You get to use and experience a much bigger picture than any developer. The only other person (or team) that has such a perspective is the designer. It is imperative that you understand the design and the reasons that it was designed the way it was. Why is it imperative? Craig Mod says it very well. You can read his article on margins and the importance of design here.
Our job, is to test the whole experience as much as it is to test each individual piece of the product. Testing the experience and design of the product is just as important as making sure a button clicks when you click it. Ensuring a good design is not only your responsibility, it is your duty.
What you can do right now
First, start by paying attention to things around you. When you catch yourself saying “I hate it when that does that.” Stop and think—did that happen because of a bad design? When your smoke alarm chirps in the middle of the night because of a low battery, think, “how could this have been a better design?”
Second, study design. Learn about tried and true patterns and why they are good, or bad. Study use cases. Look at software where design has had a significant impact on the quality of the overall package. This may be hard to do. Noticing bad design, or something that bothers you is much easier than noticing good design. It is the nuance and fine details that make something truly fantastic—and these things are not necessarily intended to be noticed.
Gaining a basic understanding of design has opened my eyes. Design is hard to do well. As such, most things are designed to be just good enough. I grew up thinking that rebooting was an acceptable solution. I thought IE6 was just fine. I thought that things were the way they were just because that is the way they were. It was only when I became interested and began to learn about design that I realized that things can be better. I realized that things can work and work well. I realized that user error is, many times, poor design. I realized that as a QA engineer, I can make a difference not just in making sure software functions, but functions well. For too long did I make misinformed decisions about how to build software. I look back at some of the software I helped build early in my career. It makes this site look decent by comparison. Okay, that may be a rather large exaggeration but you get the idea. I had to learn the good, to recognize the evil.
Adding design skills to your toolset will be one of the best decisions you make in your career. It will enable you to create better software and hardware, and help ensure better experiences for your customers. You will be able to see the details that are crucial to a good product. Even if you do not stay in the QA field, it will give you skills that translate to many other aspects of software creation. We all hate bugs. We all hate poorly designed software even more—even if we don’t know that is why we hate it. Conversely, customers may not know why they love a good product that is designed well—only that they love it. In many cases of poor design, the consequences are worse than minor annoyances and splattering bacon grease. Learn about design and help make the world a better place for all of us.