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.