What makes a good software QA person?

We have a few quirks, a hint of obsessive compulsive disorder, and we’re brutally honest. We never lie to our developers. We don’t sugar-coat, soft-shoe, back-peddle, exaggerate, or outright lie. We can’t. Our job requires us to be utterly truthful. We’ll tell it to you straight, we’re paid to be honest.

We think this stuff is funny. And it is! You have to appreciate the bug found in the wild, the "disastrous misconfiguration" error message on Chrome when it finds a "weak ephemeral Diffie-Hellman public key" (it has to do with TLS encryption), or the mall TV screen showing a Blue Screen Of Death. It’s free entertainment, but it also makes you think: what got missed that this bug escaped into the real world? How do I find a bug like that? How would I reproduce this bug? We know other people don’t always appreciate the humour in a good bug find, but a QA always will.

We’re in the details. There’s a slight correlation between being a good Dot Net developer and having blue eyes, based on two companies I've worked at. I notice colours, including eye colours, and I’m always looking for patterns. I spot when someone has matched their glasses, fingernails, shoes, toenails, and purse. If a line on a user interface is bumped down by a pixel partway along, I’ll see it. The fact that there are different numbers of steps between floors in my office building is a source of amusement, and some floors are a prime number of steps apart. When you use the back staircase, you get different numbers of stairs between floors. In the main stairwell, the door out isn’t on a consistent side as you go up the stairs, sometimes it’s on the south side, sometimes on the west. We live for details and patterns, sequences and clean lines.

We need more input, more tools, more tricks, more ways to play. More languages, more front-end and more back-end knowledge, and the stuff in between. Once we know about injection attacks, we'll test that everywhere we can. We're the reason you have client-side and server-side validation. "Why" and "how" are the most used words we know, followed by "what if". We're not trying to take your job, we want to know enough that we can see the weak spots in the armour, right where you think we could never shove a buffer overrun but we do it anyway. We have an insatiable need to learn and we're not afraid to be the least-informed person in the room while we pick up something new.

We ask a lot of questions. Some of them we already know the answer to, we're trying to show you something in a gentle and non-confrontational way. Some of them we have no idea what the answer is, and it may be an obvious or dumb question to a developer, but we need to know. Asking questions is one way to find out. Breaking stuff is another, and scenario questions ("what if the user does X or Y") are a third. We have an idea of how you're feeling from how you talk and type and move, we pay attention to that.