I have seen a lot of discussions over this topic in various blogs or otherwise. I could see people outrightly rejecting it, speaking in favor of it or making statements in favor of both approaches. I think it makes sense to write my thoughts as well on this topic. What I am going to write is a little different from what other testers have expressed so far. I am not going to give reasons for either of the opinions and strike a balance. I am a little surprised at seeing this question as a topic of debate. Instead of answers, I have got a lot of questions which you should ask yourself, before considering this as a topic of debate.
I will keep it concise. My first question, as an answer to this question is “Why Not?”. You can infact stop reading the post here and try to answer this simple question for yourself.
I learnt C, Java, Perl, Python and JavaScript. I am in the process of learning a bit of C++ and PHP. This is in addition to the vendor specific languages employed by various tools that I worked with. Am I saying that I am expert in any/all of these? No! I learnt them as and when I required the respective knowledge. Today if you ask me to code in all of these, I may be able to do so only in couple of these. But I have coded in them at some point of time and it will not take time to ramp up and be ready for new work in the same. I as a tester need not require knowledge in ALL of these languages to a developer’s level (that was not expected so far and if a project requires a higher expertise level in a particular language, I will prepare for that as well), although I came across various situations where I could not have contributed to the project without the knowledge of one of these languages.
What is there which stops a tester from learning programming? If you are an automation tester, how do you survive without programming knowledge? Didn’t you ever feel the need of developing your own utility? If you have always used an automation tool, didn’t you come across a situation where you had to play with the scripting language of the tool? What will you do if you are put into an API testing project? What will you do if you are put into a performance testing project? What will you do if you are put into protocol fuzz testing? What will you do if you are asked to use and enhance an existing scripting framework? What will you do if you are put into a Database PDM validation project where you have to extract the data yourself with the help of SQL queries crafted by you?
I don’t see a debate here. I can just see mind blocks. I can just see people defining and talking about testing with a very myopic view when they say that a tester does not need programming knowledge. I will go one step ahead and say that a tester should learn programming languages even if it is not needed for his present work.
Testing is fun. There is a variety of projects that you should target to work on. There are a lot of things to learn. I suggest to come out any mind blocks that stop you from learning. It’s your career, it’s your profession, do the best to be technically competent.
You may not be feeling the need of learning a programming language now, as per the current project requirements. How long do you think you want to or you will stay in such a project? What is the probability of getting a similar project again? What are the industry norms? Why is the industry trend showing an increased requirement for testers with more and more knowledge of technical details of protocols, products and programming languages?
I have got the answer to all the above questions for myself and my aspirations. I found that I should keep learning and comparing different programming languages, I should keep learning new technologies and exploring new areas of testing. I want to work on testing different kinds of products and execute different kinds of tests on them.
You might have got a similar answer or an altogether different answer to all these questions. If you find suitable, you can leave your comments here to extend the discussion.
Rahul Verma
Site Admin, Testing Perspective