Friday, July 29, 2011


I was reading an article this morning about how testers get and stay "technical". Go read it, and then come back. I'll wait.

There are a lot of possible rants here:
  • How is it that anyone can be involved in writing software and not know how to use basic tools of the trade? I would think any tester would learn a job's technology space just like they learn its business space.
  • Learning a tool is not the same as becoming more "technical". It's roughly equivalent to a pastry chef learning how to make a dacquoise. You're not more "pastryish"; you just know how to make a dacquoise now.
  • Eclipse is not actually required to learn Java. You can learn Java without Eclipse if you like. You're also welcome to use Eclipse for other languages. Please don't conflate the tools, the language, and the principles.
But we're going to skip the rants for now.

The thing to pull out of the thread is not to learn X language, or to learn Y tool, or that you can always go to a programmer to code something. It's this:

You should learn the things that help you do your job better.

Some things you learn are more commonly useful than others. For example, I currently work on a C library and have learned some tricks with gdb. It's pretty unlikely that I'll use that one again any time soon, and that's okay: it's still useful for now. Other things - like programming skills or the ability to have a discussion via email with a customer - I use over and over again.

One of the hard things about learning through tools is that it's sometimes difficult to separate the tool from the underlying technique. For example, if you learn QTP as a tool, does that mean you can work with Selenium? They're two different tools, sure. But some of the underlying concepts are the same. In both cases, for example, the record/playback function is not sufficient for creating maintainable test cases. So when I'm looking at a new tool, I'll frequently play around with multiple tools that do similar things (e.g., QTP and Selenium). That way I start to learn what's common between them and what's specific too the tool. Then when I'm faced with another similar tool I don't know, I can honestly say to myself, "well, I don't know this tool, but I know the principles that underly the problem space, so I should be able to figure it out." That's learning.

So don't worry about whether something is "technical" or not. Worry about whether learning something will help you. If it'll help, go for it. It never hurts to know more.


  1. Glad the thread got a response - would be nice to read the rants you had lined up :)
    ( and in defence of one of them - if you have a book that teaches Java and the book uses Eclipse then it makes sense to use Eclipse )

    I was somewhat wary of going down the techy testers route again but the 2 blogs that I read where testers seemed to be limiting themselves seemed to tie up

    Nice response

  2. Thanks, Phil! I'm going to keep skipping the rants until I have something productive to say, I think. It took me a few years to realize that there are many many testers (and devs) who don't approach jobs or problems with the same techniques and methods that I do. Nevertheless, it's true. Not all engineers learn anything beyond their very narrow trade.

    Personally, I say learn everything you can. You never know when basic vim knowledge will save the day, or that knowing the outlines of the battle of Marathon will create rapport with an interviewer and get you the job.

  3. Thanks for this; very reassuring to see someone else express these sentiments. I've never heard or read that a tester should learn how to build views in Lotus Notes and write scripts in Formula language and LotusScript, but I've learned that anyway, because it's made me (and my team) better at my job.

    Trying to learn the "right" skills -- technical or otherwise -- is no different to me than trying to follow the "best" practices. Learn what you need to succeed in your context; chances are good that effort will help you do or learn what what you need in the next context too.