Jozo asked me to elaborate on what aptitudes make a good STE. I figure that's a good a topic as any for my first real content post.

First off, I feel a need to go above and beyond our standard disclaimer and say that these are just my perspectives as an another STE. I do work with recruiting and help identify good candidates, but I'm not a lead or a manager. I have worked with a lot of people in several test organizations and there are trends that I believe make some people stand out.

When I talk about what makes a good STE I'm not really going to talk about experience. I'm more going to talk about what traits and skills are important to being an STE (I'm kind of in career counselor mode now.) I see these falling into two major categories: technical skills and personality traits.

The skills needed are easier to explain. Successful STE's really understand programming and software development. Most of the testers I work with have degrees in Computer Science for exactly this reason. Being a smart tester requires a solid understanding of how software and computers really work. So it helps if you've worked on some software projects and know a few programming languages (school is an excellent place to learn these skills.)

Personality traits are a little trickier. A lot of terms get tossed around like attention to detail, good communication skills, and creativity. These are all important, but my favorite is something I like to call being a tempered perfectionist.

That one's going to take some explaining. As a tester you are ultimately the one responsible for the quality of the product. A big part of this is finding bugs in the software, but it takes a certain perfectionist mindset to do this effectively. Noticing when you crash the program is easy, but spotting minor flaws is harder. Did that icon draw in just the wrong place? Did I select a certain shade of red, but that's more of a maroon? When I scale the text font size up does the line spacing scale up with it, is it supposed to? This is really where that attention to detail thing I mentioned earlier comes in.

But finding bugs is only part of the job. You can't fix all the bugs and your software will ship not only with bugs you don't know about, but with bugs you do know about (Joel on Software has a great article about this.) This really gets accentuated when you get closer to shipping your software. At a certain point you have to stop mucking around in the code and declare it done. This is one of the hardest phases for a tester and really where you get a chance to shine. As shipping looms nearer people will be less and less open to fixing bugs. You'll have to fight for the bugs you really believe need to be fixed. But you can't fight for them all; this is what Gretchen was talking about when she said testers need to pick their battles ... and win them.

On one hand you need to be a perfectionist to spot all the problems. But you also need to be a realist to know at the end of the day which problems are the really important problems. In a perfect world we could fix them all, but the real world doesn't work that way.

Other things are certainly important. It takes creativity to think of new ways to use and exercise your product. Good communication skills help you get along with the developers and program managers you work with, and help you accurately explain the bugs you find. But I've found it's this blend between perfectionism and realism that makes the best testers. It's a hard mix to get right, and something I work on in my personal development all the time.