This morning, I am sitting here writing a blog about tool blindness.

I am writing this blog, because I have the time to do it.

I have the time to do it, because my test environment is down.

My test environment is down because someone is installing and configuring and troubleshooting a new testing tool.  They have been since around the middle of the day yesterday, and an email just came out reiterating how important it is that everyone stay the hell out of the system until further notice.

We love tools here.  We have gobs of them.  We have even documented, at least to the acceptable level of most of the testers, that we have so many tools they actually affect the accuracy of our test results at times.  The managers don’t necessarily agree with that.  But I think about the last thing we need is another tool.  And I say that as a tool maker and seller.  Yes, another tool is not always the right answer.

I know it is just my opinion (Okay, thanx to James and his introducing me to the concept of Epistemology, at this point I think everything I think I know is just my opinion…ouch, my head is gonna explode) but…

When you spend more time installing, configuring, and troubleshooting your tool than using your tool to learn about your application, you’re not testing anymore.

When the value of the 10% of information a given tool will give you is more important than the other 90% of the information you can get without it, I am not sure you’re testing anymore.

When being able to say “On line 10 of method Foo in class Bar you have a memory leak” is more important than being able to say “6 out of the 10 primary business processes I have tested failed to meet my expectations, with me being a reasonable proxy for an average user”, I am not sure you’re testing anymore.

To me, these activities smell a lot like analysis and development.  And more and more, I am beginning to believe that tool blindness is both a symptom and a cause of this kind of behavior. I love tools.  I make them, I sell them, and I use them.  But I am always cautious to keep in mind that the tool is only that, and that the key to testing is the active involvement of people with brains, and skill.  And when the behavior of myself or anyone else on my team begins to look like tool usage for the sake of tool usage, so that statements can be made such as “We are doing good testing because we are using Super Snooper” or “If we don’t use Super Snooper, then we can’t be doing good testing”, I think tool blindness is setting in.

Begin with the end – and I don’t think any management team every created a test team with the express purpose of having them tool up.  When you are holding up testing on a semi-permanent basis to play with your tool, I think you have lost sight of the end.

Play with that tool too much, and you may just go blind.