What makes a great QA Engineer?

It's easy to recognize a good QA engineer when you find one. The obvious job-description answers are:

• strong attention to detail
• good technical knowledge
• has a few years of experience
• has a good attitude
• excellent verbal and written communication

Easy enough - we've all seen that list. So what makes a great QA Engineer?

Let's break down our fictional job description and look at the specifics.

• Strong attention to detail
  This really means that you have a neurotic ability to come up with potential failure paths subconsciously. This usually happens to me in the shower, while brushing my teeth, or on the way in to work. My favorite right-brain-assisted discovery happened in the middle of a brutal ship week. I had gone home after working 20 hours straight, and had been asleep for just a few hours when I began dreaming about a very specific bug. I woke up, ran into my home office, and tested my dream hypothesis: sure enough, it was a real bug, and a significant enough security flaw to be a show-stopper. From talking to other QA engineers, I've found that dreams about testing and debugging are very common.

• Good technical knowledge
  Of course being familiar with the technology is important. But it's more than that - the best QA Engineers have a very unusual blend of strong rational thinking skills and intuition. Technical knowledge is critical, and so is having the faith to act on your own intuition. But intuitive testing is a black art - it's very easy to waste days and days pursuing random memory corruption, or perhaps a bug in Netscape's Java class. You need to find a mix of the two - intuition to tell you where to look, and rational thinking skills to to isolate exactly when and where a problem occurs.

• Has a few years of experience
  Have PATIENCE. Sometimes you'll be snapped at, insulted, or ignored outright. Learn to recognize when an engineer is or is not interruptible - this is one of the most important skills you can bring to your department. Having this skill will quickly make you a favorite and elevate your influence. Ignoring these signs will cause the developers to complain to each other about what a pain in the ass you are. Don't be surprised when your feature requests are ignored.

  Another critical skill that comes with experience is knowing how to choose your battles. Not all your bugs can be fixed, so don't insist that they must be. Everything is a negotiating process. Your role is to define the bugs that will cause more problems than others, and do your best to explain the bottom line. If a similar bug caused 2000 support calls last year, don't be afraid to say so. And at the end of the day, recognize that you are all on the same team and working toward the same goal: to make your product as good as it can be.

• Has a good attitude
  When you see something really cool, get excited about it! Programmers often spend so much time alone working out a particular problem that they can lose sight of why they started writing a feature in the first place. Want QA to be taken more seriously in meetings? Then don't let every word that comes out of your department be a problem. It's more than OK to ask questions about features - as long as they've got time, all programmers love to talk shop.

• Excellent verbal and written communication
  Get out of your chair and walk over to talk to your developer face to face. If you're in crunch time, it's good to give a heads-up (see Interruptions). Programmers aren't always the most social animals, so no matter what happened yesterday, don't go in with a chip on your shoulder today. Maybe the most important thing is to remember that as weird as they can sometimes be, programmers are people too - so try not to assume the worst. Here's a great case in point:

  A few years ago, I was matched with a programmer to work one-on-one on the audio component of a project. Although I was still very junior, I was chosen to head up the QA effort on this component because I had several years of experience working with digital audio. I drew up a list of questions and bugs, and scheduled a meeting with my engineer. When we sat down together, the conversation went something like this:

  QA tester: "Hey, so I wanted to ask you about a few things."
  Programmer:"Great! Would you like an overview of the new features I'm working on?"
  QA tester: "Yeah, that'd be great."
  Programmer: [cue best boring professor drone] "Digital audio is a way of representing a sound wave using ones and zeroes. If you use more ones and zeroes you will have better sounding audio. You store the ones and zeroes in files on a hard drive. When you want to play back the sound, the computer sends the ones and zeroes to your soundcard, which then converts the ones and zeroes to a sound wave, which gets played through your speakers."
  QA tester: [patiently waiting for the Digital Audio for Dummies lecture to end]
  Programmer: [not stopping anytime soon]
  QA tester: [fifteen minutes later] "That's a really good overview of digital audio. I was actually specifically wondering about how we'll be doing the QuickTime integration, because we'll need to make sure we sync the onscreen vu meter to the actual audio output. Currently there's a 2 second lag which can be pretty confusing for users..."
  Programmer: [mildly confused look, patiently tries to explain it again, more slowly this time] "Digital audio is a way of representing a sound wave using ones and zeroes."
  QA tester: "Yeah, I -"
  Programmer: "The quality of your audio depends on how many ones and zeroes you use to describe it."
  QA tester: "Yep, hey, did I ever mention that I love digital audio? In fact, I was the technical editor for one of the first books on MP3 audio last year-"
  Programmer: "The computer sends the ones and zeroes to your soundcard..."
  QA tester: "Oh, whoah, hey, look at the time - jeez, I'm sorry, I have to run to a QA meeting! I'll email you a list of questions."

  I met with this same engineer several times over the next two weeks, and every time it was an identical conversation. After a while I got frustrated and even a little paranoid. Why does he think I'm an idiot? Do I just look stupid? Is he talking down to me because I'm a woman? I tried talking to him in only highly technical terms, but I still couldn't get through to him, no matter what I said. Then one day, a breakthrough came! I was at the whiteboard, explaining how I wanted a feature to work, and something clicked. I explained a new solution to a user-interface problem he'd been puzzling over for a while. From that moment on, he stopped talking down to me, and listened carefully to what I said. I could not have been more proud of myself, and I secretly counted that moment as a major victory.

  Several weeks went by, and a very senior QA engineer joined the team. One afternoon we got to talking about an audio feature, and came up with a few questions for the audio programmer. Together we walked over to talk to him, and I was astounded to watch him give the same lecture, nearly verbatim, to any questions the senior QA engineer asked. I wish I could say we came up with a clever comment, but we both sat there with our mouths open. To my further surprise, when I restated the same questions, the programmer listened to what I had to say and answered thoughtfully. My more senior coworker was every bit as insulted as I had been - maybe more so. But we figured out what was going on after he got the same infuriating treatment for two weeks straight. That programmer didn't know a single thing about digital audio when he began this project - he taught himself everything from reading books and researching on the web. He wasn't trying to insult anyone - he was just as dense as a post. He didn't know anything about digital audio, so he assumed that no one else would, either. It took him two weeks to get the basics down - he was just giving the rest of us time to catch up. Moral of the story? They really aren't out to get you. Being paranoid helps no one.

  Until next time... Have fun and don't take yourself too seriously!

  ~Lorna

  Features Index | Home | Forums