Test Personality Traits

I've begun to wonder what affect personality traits have in testing. The main question I pose to you is: are there specific personality traits that one should look for in good testers? This isn't to say that there aren't people who are excellent testers who have personality traits that aren't amiable to testing, but I'm looking for some generic pattern.

Take cynicism. Cynical people could be described as untrusting. I think it could be argued that this is a good trait to have in a tester. If by nature one does not trust the very inputs, outputs, data flows, and processes of a system system under test, it is possible that one could find more problems, assuming that there is proper motivation to do so.

On the opposite side of the spectrum, what about optimists? If you by nature are a very trusting person, would you unknowingly overlook problems due to your sunny outlook? Or is it possible to seperate your innate optimism from the technical job at hand?

You can probably already read my biases in the writing above, but I'm curious what the world at hand thinks. I'm not suggesting that hiring people should be based on personality traits, especially since I think it is impossible to get a good feel for someone's personality in 4-5 hours; but perhaps, just maybe, it should be taken into account.

The Brotherhood of Building and Testing

In the past few weeks, I've been embedded in the world of build engineering and configuration management. It has been an eye-opening experience, believe me. There are many splinters and specializations in the software industry, and the area of build engineering is one that I've never really paid attention to until recently. From what I've seen thus far, there are far more connections between building and testing than I've previously known.

There is a web of trust in the process of building any project that one takes a bit for granted, and indeed one must take it for granted. It's impossible to know every detail that every responsibility entails, so you must take for granted that the program manager is doing his job, and the product manager's requirements have been adequately reviewed and vetted out. The one area where the web of trust stops is between developer and testers. The testers are present to be cynical, and in general not trust the output of the developers. This ensures more quality in the software so that the users are not the ones consuming poor products.

I've recently started to think that the web of trust should be breaking down in another place: building. I would say that most engineers take the output of the build engineer a bit for granted. You assume that the build is an instrumented build because the build engineer says so. You assume that the build has the correct fixes in it because the build engineer says so. Well what happens if the build engineer is wrong? Having the correct build is the first step in the testing process, and depending on where you are in the life cycle, the main consumer of the build will be the testers.

I don't think it's too far-fetched to say that a new specialization should open up: build test engineer. The process of building can be complicated enough, depending on the size of your project, and can be a full-time job by itself. Adding value on top of that could be another full-time job. The value I'm referring to is build testing, build metrics, and build consumption.

Just as testers are considered a trusted third-party that can tell you with certainty (i.e., data) the risks and issues found in a product, a build test engineer would be a trusted third-party who could tell you with certainty that the build has or contains the attributes it says it does.

Nerdiest. Comic. Ever.

This is a bit off topic, but xkcd had quite possibly the nerdiest comic ever tonight, and I thought I should share with you all. It involves Lisp, God, and Perl.

http://xkcd.com/c224.html

Amazing.

The Desire to Build

My girlfriend and I had an interesting conversation last week about how so many test engineers feel the need to create and recreate tools upon more tools, even if a tool already exists that does what they need to do. This is a situation that has its own acronym: YATT (yet another test tool).

It brings up an interesting question: does this desire come from the very core of what it means to be an engineer, to build and create; or is this possibly something more? Is it possible that this desire stems from deeper feelings of inadequacies at not being a "developer", at least in title? When you need a test tool to perform an action, and there are twenty tools out there already that do this, why should one create another tool?

It's true that some stigma remains around the role of the tester. When people ask what I do, I feel the need to stress that I'm an engineer, but in the testing field. There are times at work when I feel I should be creating something in order to be taken seriously by my fellow engineers. I feel this is true, at least in part. Doing your job, and doing it well, is an exceptional way of getting respect, but there is nothing like showing off something cool to get instant cred. It's like we're in 8th grade again.

Which brings up an interesting conclusion that we came to in our coversation. The testing field needs to a mature a little before such problems will be alleviated. I think that when testing is taken as a serious discipline across the industry, testers will stop trying to be developers and start trying to be testers.