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
Mr. Rahul Verma,
your absolutely right it doesn’t mean that you don’t program you didn’t also have to learn programming. nothing could stop you from learning especially if your job is somehow related to programming. it is absolutely true that your project doesn’t always stay the same. so you have to learn something new so that you wouldn’t be behind from others.
Hi Marie,
It’s good to hear that you share the same opinion about testers learning programming langauges.
People tend to see testing confined to their current or past assignments. If they sit down and plan their testing career, the requirement of learning atleast one good programming language immediately pops up.
Keep visting and sharing your thoughts.
Regards,
Rahul Verma.
The best testers that I have come across always had a decent exposure to programming and may have worked previously as developers too. I feel that if the tester understands the programming language (need not be an expert), they can actually be much more effective while testing
Also your comment regarding need of programming skills wrt automation is spot on, In my opinion a test engineer who cannot automate is missing out on a lot.
Regards
Lohit
Hi Lohit,
I share the same opinion. Testers with knowledge of programming can think about possible internal implementations. In the process, they can come up with interesting test cases.
E.g. you can think of command line options being passed to a hash (mapping). Now a tester with this knowledge will try to validate how the program treats duplicate options, which overrides what and whether there is any logic which checks duplicacy before pushing the options to the mapping (so that overriding does not occur). This can help him write better bug reports as well. Further if he can imagine the options being pushed to internal buffers, he can try playing with them in various ways to corrupt internal buffers.
Regards,
Rahul Verma.
@Lohit,
The best testers that I have come across always had a decent exposure to programming and may have worked previously as developers too. I feel that if the tester understands the programming language (need not be an expert), they can actually be much more effective while testing
It makes me ask what you think testing is?
If you are under an impression that testers with programming skill can do effective testing then what is “effective testing”?
In my opinion a test engineer who cannot automate is missing out on a lot.
Missing out a lot of what?
Money?
Bugs?
Ideas?
Opportunities?
Fun?
Interviews?
@Rahul,
Testers with knowledge of programming can think about possible internal implementations. In the process, they can come up with interesting test cases.
Internal implementation is independent of programming skill.
I was curious to know why I was hearing a noise whenever a head phone that I was testing crashed. I asked for the reason of noise.
I was briefed about ring buffer and that the buffer should clear its contents on switch off. The noise was heard because the buffer was trying to flush all the data out to speaker than clearing it.
With that understanding, I was able to design tests for the buffer and did find bugs that were deemed very important.
Also…
Give me an example of an interesting and non interesting test case.
Add 1+1, and if it helps a tester find a bug that is important, its a fantastic test.
Add 39483984e9834 and 938483e93488 and doesn’t help a tester find a bug, its not as fantastic as the previous one for the moment.
In General:
I am a tester. I primarily test software. I focus on cost v/s value. Cost of doing something v/s the value it brings to my testing effort and the value it brings to my client for having hired me. If there is tremendous or significant value in writing code that tests software I’d like to do it. However, if I lack programming skill but is a good test designer, I’d sit with a developer or with another team member who might know programming and get test scripts written that help me achieving the value I love to see.
Each of us are not sent to Mars all alone and asked to test software without anyone’s access or help.
Most of us work in teams and teams need to be diversified to reap maximum value. All people knowing to dig a tunnel but no one knowing how to get the water that might spurt out of the tunnel are useless.
There are way too many programmers in this world than people who can “think” of diversified ideas that can help uncover a lot of bugs. I always have been able to find of a programmer ( at office / at my client’s place / at some portal who love doing such stuff for people like me )
Here is an interesting thing I learned from Michael Bolton: We test code. We write code to test code. We want to uncover bugs in the code we test and we write code that also have bugs.
A lot of testers are under an assumption that test code doesn’t have bugs at all.
Rapid Software Testing ( http://www.satisfice.com/rst.pdf ) gives wonderful insight about tools. It says, “A tool is anything that helps a tester to perform his job efficiently”. I automate a lot of stuff, for instance I use notepad, word, excel.
Should testers learn programming?
Well, I can answer a question “Should Pradeep learn programming?” and I know that others can’t answer and I belong to the “testers” you are talking about.
Only I can answer what I “should” learn!
Think of this: What are the things that might be interesting for most of the testers to unlearn?
While learning alone cannot do great things, unlearning could also help.
Hi Pradeep,
Thanks for sharing your thoughts on this post.
I know the amount of passion you have for software testing and the kind of effort you spend in learning regarding testing and sharing your knowledge.
You have raised quite a few questions. For clarity sake, I am splitting my answers across sections:
Extending my thoughts
The intention of this post is also to encourage testers to learn more. There are certain areas of testing where you can not do without programming knowledge. One example is performance testing. One can not execute a performance test for a client-serve application manually. And because one has to automate it, one should know a tool. As you would agree, no tool is complete in itself. It requires a tester’s intervention in the form of script enhancements and framework design. For this, a tester needs to learn programming.
Another example is API testing. When one is put into an API testing project, he can not consult a developer for every other thing. He might get an API doc and beyond that if there is an API testing tool, it’s still fine else he has to come up with your own API testing framework. For this, a tester needs to learn programming.
In the field of security testing, there are plenty of tools and many a times they don’t fit to your situation. One might have to extend an existing tool and write your own.
There are functional testing projects for which many aspects have been automated and if a tester becomes a part of the team, he might have to work on the same as well.
Now, a tester can get rid of all these situations by not applying for a performance testing/API testing/automation testing/security testing job. He can always choose to stick to manual testing projects, which can be very challenging as well.
It’s just a matter of choice but I suspect that without programming knowledge the choices become quite confined. When I think of my testing career, I think of working on a lot of technical projects where I am actually involved in developing a lot of testing utilities.
Interesting and Not Interesting test cases
Personally I do not measure my interest in a test case based on whether it found a bug. A very simple test case might find a bug. I may not feel happy about it. I enjoy investigations, which make me learn more about the product. Such investigations may or may nor find bugs.
About taking team’s help in programming
It’s a good idea. I too take help of the team when some programming issues arise.
But I can not depend on any person to develop the complete code for me. I am in an individual contributor position.
I remember a situation in onsite project where we as a team were working in a LoadRunner project for a bank. Each one of us was jam packed with work. Do you think it will be feasible in such a situation to ask someone to code for me? Otherwise too, it’s better to be self-dependent. A tester should be able to write small utilities for him.
About Tools like notepad, word and excel
Yes they are tools. But they truly become a lot worthy tools when we use some kind of macro with them (not possible with Notepad).
I had extensively used MS Excel macros to automate analysis and plotting of performance metrics. But once again, to save time, one needs to learn VBA Macros here. When a tester is dealing with a large amount of data, automating data analysis (plotting and trend analysis) saves a lot of time.
About Test code having bugs
I agree to you on this point. Frankly I never consider any code bug fee whether it is a product or a code written to test it. I tend to reevaluate test code at regular intervals.
About Unlearning
Unlearning is quite a tough task. I usually get around this limitation by learning a new thing to substitute the previous one. E.g if I followed a wrong approach for automation, when I realize it, I substitute it with new and better approaches. My brain has limited space, I tend to remember only the latest things
It was very interesting to answer your comments, even better than writing the original post. I hope that I addressed some of the questions you have raised.
Regards,
Rahul Verma.
@Rahul,
The intention of this post is also to encourage testers to learn more. There are certain areas of testing where you can not do without programming knowledge.
Programming is the most common encouragement that testers worldwide receive and hence it is nothing new.
For instance, you might want to encourage on lateral thinking, critical thinking, systems thinking.
There are not just a few but a lot of complex problems that can be solved with the above mentioned thought processes.
One example is performance testing. One can not execute a performance test for a client-serve application manually.
Rahul, what do you define performance as?
If I am just one client connected to the server requesting for information and it appears to take a minute to respond to my request, and I note that observation to perform tests to find more such information – what am I doing?
Sending 1 million SMS might be a job that humans might want to automate as a part of testing a mobile phone but that doesn’t mean sending a few SMS is not possible by humans.
And because one has to automate it, one should know a tool. As you would agree, no tool is complete in itself. It requires a tester’s intervention in the form of script enhancements and framework design. For this, a tester needs to learn programming.
The question would be: Will it be valuable if I do so and not just will I be able to do it.
Another example is API testing. When one is put into an API testing project, he can not consult a developer for every other thing. He might get an API doc and beyond that if there is an API testing tool, it’s still fine else he has to come up with your own API testing framework. For this, a tester needs to learn programming.
If you were a manager, would you put a tester who is not proficient at programming in API testing and force him to do it?
If your answer is No then in my experience – only those testers who claim to know something in programming are put. So they already know and need practice of programming.
In the field of security testing, there are plenty of tools and many a times they don’t fit to your situation. One might have to extend an existing tool and write your own.
In all fields there are plenty of tools and anyone who wants to extend it can.
He can always choose to stick to manual testing projects, which can be very challenging as well.
Manual – if it means – involving a human being
How different a testing are you ( the programmer tester ) doing?
If manual testing involves thinking of a human being to test software so does your automation require thinking by human beings.
Both are manual!
It’s just a matter of choice but I suspect that without programming knowledge the choices become quite confined
Those having written code to test software NEVER have wanted to switch to the manual testing you referred to and hence the options for those who write code to test software is also confined.
However, the options are not dependent on what the person knows but depends on how he can put to his use whatever little he knows.
I remember a situation in onsite project where we as a team were working in a LoadRunner project for a bank. Each one of us was jam packed with work. Do you think it will be feasible in such a situation to ask someone to code for me?
Maybe there was someone nearby your cubicles who might have loved to do it. I always find them! I found them when I was in McAfee, too.
If you ask me will it be feasible?
I would say “no” with the traditional ways of asking that you might be thinking.
You might want to find people within your organization who can help you with such tasks and in turn you might want to offer something that they might want.
I agree to you on this point. Frankly I never consider any code bug fee whether it is a product or a code written to test it. I tend to reevaluate test code at regular intervals.
If re-evaluation can find bugs in a test code, why not re-evaluate the code that is written for the customer than to write test code?
So what about programming skill for a tester?
There are a huge set of skills that testers could have to do effective testing. One of the obvious things is programming.
A team if were to be an effective team has to be diversified. I’d like to remind the tunnel men example above: All men digging a tunnel without anyone knowing how to put the water spurting from the tunnel out of it is a debacle of work.
When we are generalizing and saying things like : Should testers learn XXXX? We are ignoring the fact that our experience is very limited and we are not aware of so many thousands of contexts in which a lot of other testers live.
Instead, we might want to re-phrase the topic and discussion as:
What kind of testers would need programming as a skill?
What kind of test activity can be done more efficiently when programming is used to write test code?
What contexts would suffer if a tester is not aware of programming or does not find one?
@Rahul,
The intention of this post is also to encourage testers to learn more. There are certain areas of testing where you can not do without programming knowledge.
Programming is the most common encouragement that testers worldwide receive and hence it is nothing new.
For instance, you might want to encourage on lateral thinking, critical thinking, systems thinking.
There are not just a few but a lot of complex problems that can be solved with the above mentioned thought processes.
One example is performance testing. One can not execute a performance test for a client-serve application manually.
Rahul, what do you define performance as?
If I am just one client connected to the server requesting for information and it appears to take a minute to respond to my request, and I note that observation to perform tests to find more such information – what am I doing?
Sending 1 million SMS might be a job that humans might want to automate as a part of testing a mobile phone but that doesn’t mean sending a few SMS is not possible by humans.
And because one has to automate it, one should know a tool. As you would agree, no tool is complete in itself. It requires a tester’s intervention in the form of script enhancements and framework design. For this, a tester needs to learn programming.
The question would be: Will it be valuable if I do so and not just will I be able to do it.
Another example is API testing. When one is put into an API testing project, he can not consult a developer for every other thing. He might get an API doc and beyond that if there is an API testing tool, it’s still fine else he has to come up with your own API testing framework. For this, a tester needs to learn programming.
If you were a manager, would you put a tester who is not proficient at programming in API testing and force him to do it?
If your answer is No then in my experience – only those testers who claim to know something in programming are put. So they already know and need practice of programming.
In the field of security testing, there are plenty of tools and many a times they don’t fit to your situation. One might have to extend an existing tool and write your own.
In all fields there are plenty of tools and anyone who wants to extend it can.
He can always choose to stick to manual testing projects, which can be very challenging as well.
Manual – if it means – involving a human being
How different a testing are you ( the programmer tester ) doing?
If manual testing involves thinking of a human being to test software so does your automation require thinking by human beings.
Both are manual!
It’s just a matter of choice but I suspect that without programming knowledge the choices become quite confined
Those having written code to test software NEVER have wanted to switch to the manual testing you referred to and hence the options for those who write code to test software is also confined.
However, the options are not dependent on what the person knows but depends on how he can put to his use whatever little he knows.
I remember a situation in onsite project where we as a team were working in a LoadRunner project for a bank. Each one of us was jam packed with work. Do you think it will be feasible in such a situation to ask someone to code for me?
Maybe there was someone nearby your cubicles who might have loved to do it. I always find them! I found them when I was in McAfee, too.
If you ask me will it be feasible?
I would say “no” with the traditional ways of asking that you might be thinking.
You might want to find people within your organization who can help you with such tasks and in turn you might want to offer something that they might want.
I agree to you on this point. Frankly I never consider any code bug fee whether it is a product or a code written to test it. I tend to reevaluate test code at regular intervals
If re-evaluation can find bugs in a test code, why not re-evaluate the code that is written for the customer than to write test code?
So what about programming skill for a tester?
There are a huge set of skills that testers could have to do effective testing. One of the obvious things is programming.
A team if were to be an effective team has to be diversified. I’d like to remind the tunnel men example above: All men digging a tunnel without anyone knowing how to put the water spurting from the tunnel out of it is a debacle of work.
When we are generalizing and saying things like : Should testers learn XXXX? We are ignoring the fact that our experience is very limited and we are not aware of so many thousands of contexts in which a lot of other testers live.
Instead, we might want to re-phrase the topic and discussion as:
What kind of testers would need programming as a skill?
What kind of test activity can be done more efficiently when programming is used to write test code?
What contexts would suffer if a tester is not aware of programming or does not find one?
Hi Pradeep,
So, you are back! I expected this as you are one of the few testers I have come across who pose a good, generous debate.
I am trying to address some of the points raised by you. I hope, this will make my thoughts clearer and convey things which probably the earlier contents did not.
About Programming and Systems thinking
I know that many people encourage testers to learn programming languages (all for good). I never said that I am suggesting something new. I am playing my part and emphasizing its use. Just to extend, systems thinking as an idea has been discussed so many times by testers from Context Driven School. But that shouldn’t and that hasn’t obviously stopped you from suggesting it as something testers should learn.
I have seen quite a few discussions naming lateral thinking, critical thinking, systems thinking as areas of learning for software testers. They are on my personal learning plan. When I learn them, you will definitely see me writing about them as well.
About Performance Testing
Connecting a single client and measuring the time is measuring performance, but it hardly conveys any meaning. Taking a few SMSs is not a performance test realistically speaking because the servers that handle them are much more capable and you will not be able to test their performance by sending a few SMSs. As you mentioned, sending a million SMSs will fall into this category depending on the performance goals and that definitely need to be automated.
About Manager’s decision of putting a tester on projects
You are correct. A manager will not put me into a project that requires programming knowledge, if I do not know it. That’s what my point is. If I want to work in such a project, I should keep myself ready by learning the required skill-set and grab the opportunity of working on such a project whenever it comes. We seldom get learning time when we are put into projects. Managers expect and look for people who already have relevant knowledge.
About Manual Testing definition
There is really a lot of confusion around definitions of manual testing and automation testing. Please wait for some time, I have a detailed post lined up on this topic. I will definitely address your point there along with several other interesting points.
I can just say that at present I am involved in broadly three categories of testing – manual, automated and programmed testing (because to test, I have to program an interface to the API). The third category is not typically an automated test but requires programming knowledge. So, I am not against manual testing. I enjoy all kinds of testing.
About taking help
I am still of the opinion that taking help occasionally is very different from being totally dependent on someone. If one’s job as a tester requires programming knowledge, there is not other go apart from learning it.
About testing test code
Even manual test cases go through reviews and contain bugs. That does not mean we should stop documenting test cases. Testing the product and creating and maintaining a test framework – both of these are responsibilities of a tester.
About skills of a tester
When I say, Testers should learn programming; I elaborate the breadth of testing and not confine it to a limited set of projects. Nowhere, I mentioned that Testers should learn ONLY programming. The skills you have mentioned are essential for being a good tester. Every tester would yearn to learn them. That does not mean he should not learn programming.
As for rephrasing the topic name, I guess I have different opinion. I am still of the opinion that all testers should learn programming. This will broaden the possibilities of projects in which they can work and contribute well.
Pradeep, on a concluding note for my comment, I want to say that you as a tester have immense analytical skills and that makes you fit for a lot of testing projects. If you learn programming, this would not make you forget your present skills. But you will become eligible for a lot of other kinds of projects, which require programming skills. That’s what I said as widening of the scope. I have never belittled manual testing or the analytical skills that a tester requires (how can I!). I just want to say that there are many things to learn beyond this too.
Thanks for the visit.
Regards,
Rahul Verma.
Hello Sir,
i am sachin, and i am working in an MNc in pune as manual tester from last 13 months.Iwant to improve my skill set and practical knowledge in Testing domain, so please recommend me some usefull sites,books,courses if any. Also i am very consious about career in Testing domain, so please guide me as what should be done to grow in this market. Waiting for yours positive reply.
Thanking you,
Sachin
Hi Sachin,
I feel more comfortable being addressed by my first name.
I want to improve my skill set and practical knowledge in Testing domain, so please recommend me some usefull sites,books,courses if any.
Only your job can teach you practical skills. Books, websites, discussions are to understand the concepts and carrying these concepts back to the job.
From the Wild Wild Web section of the Testing Perspective website contains a lot of useful links to software testing resources. In addition to this you can find the latest blog post links on the TP Wiki.
Visit all the links provided and carefully assess what looks convincing to you. Bookmark the shortlisted ones and regularly follow up the latest articles on those websites/blogs.
Also i am very conscious about career in Testing domain, so please guide me as what should be done to grow in this market. Waiting for yours positive reply.
You are at the early stage of your testing career. It is good that you are trying to plan things for yourself. For suggesting what is good for you, we might need more than this comment to discuss. Let’s discuss this via emails. Please write an email to me at — rahul_verma@testingperspective.com to discuss on this further.
@Rahul,
First of all, Pradeep knows programming. The LVT tool that the company you currently work for was developed and maintained by me till I was there 😉
Second, You might want to start using Computer Assisted Testing for the three categories you have.
About Performance Testing
Connecting a single client and measuring the time is measuring performance, but it hardly conveys any meaning.
Oh Really!
I think it conveys a lot of meanings:
a) The system isn’t still good enough to take a much bigger load.
b) The investment on tools ( if any ) to support further performance testing can be delayed.
c) The design might want to be re-worked.
d) The code might need a re-look.
e) The next release or build ( if it claims to have the fix for the observations ) shall receive focus on the kind of tests that were performed to note the behavior.
If I want to work in such a project, I should keep myself ready by learning the required skill-set and grab the opportunity of working on such a project whenever it comes.
Now this statement of yours has the “I” heuristic that is appealing.
As you say, “If *I* want to work on such a project *I* better know how to code else *I* know I’d be missing opportunities as managers look for people with the know how.
Here is a suggestion: If *I* were to be blogging about a similar topic in future, I’d rather use the “I” heuristic – list the things I could do as I could program and list the opportunities I got because I knew how to test plus I knew how to code and leave the question open ended to the reader to figure out what he/she needs to do to get in to similar projects.
That in my opinion makes the post more powerful and influential.
*I* might be wrong!
Hi Pradeep,
First of all, Pradeep knows programming. The LVT tool that the company you currently work for was developed and maintained by me till I was there 😉
It is good to know this point. I would like to see more testers having such knowledge so that they can work on projects similar to what you did for LVT.
Second, You might want to start using Computer Assisted Testing for the three categories you have.
I find that the term Computer Aided Testing is very ambiguous when used in the context of knowing what kind of testing is being done.
Shrini suggests this term to be used for Automation testing. You suggest it to use for all three. Personally, I am quite happy with the terms Manual Testing and Automation Testing as most of the testers around are comfortable with this terminology. Everyone knows the context in which these terms are used so why devise new terms to overload the already existing enormous terminology in Testing further.
About Performance Testing
Oh Really!
I think it conveys a lot of meanings:
a) The system isn’t still good enough to take a much bigger load.
b) The investment on tools ( if any ) to support further performance testing can be delayed.
c) The design might want to be re-worked.
d) The code might need a re-look.
e) The next release or build ( if it claims to have the fix for the observations ) shall receive focus on the kind of tests that were performed to note the behavior.
Pradeep, I can see that you are not quite clear about the purpose of performance testing. The points mentioned by you come under functional testing and not under performance testing. A single user access to a website can not give you any information whether it will be able to take a bigger load, neither it can give any idea about investment in performance tools. The kind of design relooks and code relooks which might arise in this case, will be more of functional perspective rather than performance perspective. It can just convey whether a user is able to browse the functionality of the website and whether the site is down.
Now this statement of yours has the “I” heuristic that is appealing.
As you say, “If *I* want to work on such a project *I* better know how to code else *I* know I’d be missing opportunities as managers look for people with the know how.
Here is a suggestion: If *I* were to be blogging about a similar topic in future, I’d rather use the “I” heuristic – list the things I could do as I could program and list the opportunities I got because I knew how to test plus I knew how to code and leave the question open ended to the reader to figure out what he/she needs to do to get in to similar projects.
That in my opinion makes the post more powerful and influential.
I think what I am saying is not applicable to just me in the testing community. There are many who find this in context to their own career. No writer can boast that his writing is for all. Still, he or she chooses to label his articles as generic. I am also comfortable writing in a generic sense rather than writing it like a diary with lot of “I”s sprinkled here and there.
Yes, I got a lot of opportunities because of the way I am handling my career in testing. Suggesting this as a generic approach doesn’t harm. Overkill will be when I say that to get a job “a” in Company “b” under “c” manager, do what I did and then put it as a generic literature. I didn’t do it!
What I wrote is quite generic. I know a lot many testers, who share the same thought.
*I* might be wrong!
Now, that’s a good punch! It’s not about being right or wrong. It’s all a matter of opinion (or to advertise my site…of testing perspective!)
I hope you too are enjoying this discussion to the extent as I am.
Keep visiting!
Rahul Verma.
The points mentioned by you come under functional testing and not under performance testing
Kindly define performance testing.
Hi
Looks like I missed out on an interesting discussion because I did not subscribe to the comments 🙁
Even though its delayed, Pradeep here are the answers to your questions
Testing : how do I define testing, well good question 🙂 I would say validation of the functionality, usability , ensuring that when things go wrong users know what hit them etc etc.
Effective testing to me is to ensure we attempt to provide as high a quality product to the end user as possible (with the old constraints of time and money 🙂 thrown in as party pooper’s)
Answer to the second question : Maybe ALL of them, but chief among them would be bugs, ideas and FUN
To me knowledge of programming is an added arrow in the test engineers quiver, a tool among many other tools
Regarding test code, its an interesting thing you brought up, I wanted to share a recent incident, my Dev colleagues use some of the QA regression suites, and do complain point out the mistakes that we did
We thank them and try and fix those, and do tell them that this too is a piece of code, prone to errors and breakage
Thanks
Lohit
@Lohit,
Testing : how do I define testing, well good question 🙂 I would say validation of the functionality, usability , ensuring that when things go wrong users know what hit them etc etc.
Effective testing to me is to ensure we attempt to provide as high a quality product to the end user as possible (with the old constraints of time and money 🙂 thrown in as party pooper’s)
Testers find bugs. By merely finding bugs there is no improvement of quality.
Let me assume that you argue : when developers fix a set of bugs, testers have contributed to the improvement of quality.
Testers might have contributed to further degradation of quality if developers introduce more bugs while fixing them and there is no way to know how many bugs they introduced.
Your definition of testing has a word “validation” to it. What’s validation?
If you ask me to explain what an amplifier is and I reply like, “An amplifier is a booster kind of device” – I haven’t explained what an amplifier is.
You might want to read Jerry Weinberg, Michael Bolton, James Bach, Cem Kaner and Ben Simo to better your thoughts that can stand up to challenge from other testers.
To me knowledge of programming is an added arrow in the test engineers quiver, a tool among many other tools
I am not surprised that many testers who think of testing as a job of improving quality talking about programming.
I bet those who do this will not know what quality means.
How would you test, if you know programming without knowing what testing really means?
Regarding test code, its an interesting thing you brought up, I wanted to share a recent incident, my Dev colleagues use some of the QA regression suites, and do complain point out the mistakes that we did
We thank them and try and fix those, and do tell them that this too is a piece of code, prone to errors and breakage
This is important. Very important.
If I were you I’d learn multiple things:
a) Writing code to test code is an approach to find bugs.
b) Any code written would have bugs.
c) Any bug fixed might lead to other set of bugs.
d) Testers who do not know to write code might be good at those kinds of test that involves human intervention extensively.
e) Testers who think of improving quality has to write code and ask other people to test it, to understand that testing is not a job of improving the quality but finding information about the quality of the code based on the tests run.
f) Testers who recommend other testers to do something for achieving better testing in public forums, first should have thought critical about it or be open to criticism.
g)Testers who conclude ideas about techniques/approaches, early in their career are less likely to learn more about it or more likely become reluctant to possible better learning.
Answer to the second question : Maybe ALL of them, but chief among them would be bugs, ideas and FUN
Fantastic. It looks like automation /scripting that you are referring to : can find a lot more bugs and give ideas and fun.
Signs of an unsuccessful tester are bright enough. You might want to dim it by reading articles from the people whom I suggested.
Dont take it personally, I don’t know who you are. The picture I have in my mind is of a tester who might love testing but hasn’t been directed well enough ( by himself and or people around him )
I’d be more than happy to help you, if you’d want me to.
Hi Pradeep,
Good to see the discussion continuing.
Kindly define performance testing.
I am not quite fond of building discussions based on one line definitions, as they often turn out to be ambiguous. If you are really interested in knowing about performance testing, I guess we need to take it up as an altogether different discussion. I know that you are in the External Reviewers for one of the latest books on performance testing. I can foresee an extended healthy discussion on this topic. So, this discussion will be more fruitful if followed up at a separate place. Give me some time. I will create a separate post for it.
I would be very much interested if you can write or discuss more about the one-user approach that you discussed. I haven’t heard anything like that before, look forward to seeing some fresh discussion.
If you still feel that we can continue the discussion here itself, please let me know, we will use the same space.
== Your comments to Lohit ===
I want to answer to some of the comments you have addressed to Lohit, as I guess they are generic in nature. Meanwhile, he also might turn up and reply to you.
Testers find bugs. By merely finding bugs there is no improvement of quality.
Let me assume that you argue : when developers fix a set of bugs, testers have contributed to the improvement of quality.
Testers might have contributed to further degradation of quality if developers introduce more bugs while fixing them and there is no way to know how many bugs they introduced.
I didn’t quite get the point of discussion here. If the job of testers is not to find bugs, what do you think their role is? Finding bugs and suggesting improvements are essential part of a tester’s job. Fixing or not fixing them does not come in a tester’s periphery, though a tester can pass the information in the best possible way about the bug, which can govern such decisions. If the developer introduces new bugs for fixing a bug, finding them is again the job of a tester, that’s what regression testing is all about.
I am not surprised that many testers who think of testing as a job of improving quality talking about programming.
I bet those who do this will not know what quality means.
Now, that’s very generic statement. Do you think ALL the testers who do not know programming are always better than those who know programming? How does learning programming impact one’s perception of quality?
I am a tester. I know programming. I challenge this theory of yours in its totality.
Testers who do not know to write code might be good at those kinds of test that involves human intervention extensively.
I liked the word “might” here. Extending this, a tester with programming knowledge might also be good at the kind of tests you have mentioned, in addition to those where programming is required.
Testers who recommend other testers to do something for achieving better testing in public forums, first should have thought critical about it or be open to criticism.
Good Point.
I want to add here that a different opinion does not mean lack of thought or knowledge.
Testers who conclude ideas about techniques/approaches, early in their career are less likely to learn more about it or more likely become reluctant to possible better learning.
Once again a good point! But I see a little contradiction here in your thoughts.
If one suggests that in addition to a tester’s current skills, he should also try to add programming knowledge as a tool, he is actually being open to new learning rather than stopping it with one liner “because I am a tester, I should not learn programming” or “because my project does not require it, I should not learn programming”. Nowhere in this blog post, its comments or elsewhere, I mentioned that a tester should not learn systems thinking, puzzle solving skills or other similar stuff advocated by you. When you say that a tester does not need to learn programming, it’s actually you who is being reluctant and confining the testing field only to the mentioned skills.
Regards,
Rahul Verma.
Pradeep, to keep the discussion going, and No I am not taking the comments personally
Some of the gentleman you have referred to , I do try to follow, but like others I am entitled to an opinion
So here goes the response, and Yes I will try to marshal my thoughts better 🙂
“Testers might have contributed to further degradation of quality if developers introduce more bugs while fixing them and there is no way to know how many bugs they introduced.”
Are you suggesting we should not write code to find more bugs (or even file bugs), since more bug fixes can cause even more bugs ?
“Fantastic. It looks like automation /scripting that you are referring to : can find a lot more bugs and give ideas and fun.”
First of all you cannot automate something without manually creating the test case and then executing it. So automation / scripting no where replaces the “human expertise”.
Also despite some of the costs involved with automation, I dont think you can do away with them totally, Is that what you are proposing ?
I would rather create new test cases than execute the old ones repeatedly. I believe test teams should evolve to become test creators from test executioners alone. Automation does come in handy here.
Would love to hear from you
regards
Lohit
@Lohit,
First of all you cannot automate something without manually creating the test case and then executing it. So automation / scripting no where replaces the “human expertise”.
Also despite some of the costs involved with automation, I dont think you can do away with them totally, Is that what you are proposing ?
Test Automation script is a program.
Products, we software testers test is a program.
How did someone write the product we test without running it manually?
So, to write an automation script a manual test is not necessary.
Forget the opinion you have (just for a while) and go through this thread as though you are learning it for the first time (or) unlearn, learn and then unlearn again, if needed.
Did you go through James Bach’s Test Automation Snake Oil article?
If you haven’t google search can be handy enough.
Hi
Thanks I reread the article after quite some time,
The particular article focusses on the ills plaguing the record and replay tools, I believe the discussion we are having was generic, and included server side automation
Interesting quotes from the article
”
Let me hasten to agree that test automation is a
very cool idea. I enjoy doing automation more
than any other testing task.
”
”
This article is a critical analysis of the “script and
playback” style of automation for regression
testing of GUI applications.
”
I would say if a person has good programming skills, the automation becomes more of programming rather than record replay
Also the section is especially relevant for me
” Sensible Approach to Automation”
“Make no mistake. Automation is a great idea. To
make it a good investment, as well, the secret is
to think about testing first and automation
second. If testing is a means to the end of
understanding the quality of the software,
automation is just a means to a means”
Regards
Lohit
Hi Rahul,
I completely agree with your views mainly concerning Performance Testing (I do not have much knowledge on Manual Testing :(). I have observed an interesting comment on this discussion saying whether a manager puts a person into a team where there is some knowledge of programming required? I would say, yes, and I have faced it many times in my team. Many a times, there would be a resource Crunch in the organisation and the manager would be forced to allocate the team, in which there would be a limited number of persons who would have good knowledge of Programming. In this scenario, I agree with your idea that all the testers should be encouraged to learn Programming and this Knowledge will defenitely help in the careers of Testers. It is very easy to learn the other Programming languages once you have a good knowledge of atleast one.
Regards,
Vijay.
Hi Vijay,
Good to hear that you agree to the point.
We all know that at some stage or other, programming will help us conducting testing activities. So, the idea is that instead of waiting for that day, why not be prepared? And I personally feel that once you know it, you will yourself pull that day nearer!
Likes of Google/Microsoft are so unilateral in their “obsession” to “write-code-to-test” that for them you cann’t code you can’t test.
What do you say for such approaches. Note that they do not use the word “automation” or any other phrase – for specific style or target of coding they call as “testing” – For example : Misko Hevery of Google.
This is pretty suicidal for testing – while many good testers can code and can use “code” to generate ideas to test – pushing to do “code” – is a really bad thing to do.
Shrini
@Shrini,
I still think about programming as an essential skill for a tester. But I can take an exception. A skilled exploratory tester is rare to find (though many claim to be so). For such rare ones, I think that their thinking skills should be valued more than programming. They must never be looked down upon just because they don’t know programming, rather respected for the unique skill set which they have. We can teach programming easily but teaching how to think is trickier. It’s similar to teaching how to innovate 🙂
As a tester if one knows programming, it comes in handy when one is dealing with code, participating in code reviews, white box testing,or writing some code for day-to-day test automation activities. If one doesn’t know programming, one would miss a a lot of opportunities where one can contribute from testing perspective. We can’t expect that every time there would be someone to translate what is implemented in the code into some logic diagrams on the white board or email.
I think that a successful team would comprise of both of the above – testers who know programming and testers who are excellent at exploration. They would complement each other in a very good way.
So, coming back to your point about Google and the like, I do believe that they should hire testers of both types in the interest of product quality.
Hello Rahul,
I read all above comments and I really say Thanks to you to make available these wonderful thoughts through these comments. I feel like I got the Testing Pearls from the Ocean!!
I do agree that testers must learn programming because its always help you to understand the whole system and also its feel good when tester finds a defect and tester only propose a fix for that defect!! I took this experience. I am really enjoying now a days as I am learning C# and giving a try to write Test Methods in C#.
Thanks,
Mangesh
Hi Rahul,
And I thought I was alone !! I completely agree with you. Tester should know how to code, primarliy for 2 reasons:
1) They can develop tools so that they can automate some of the work that they do apart from testing. I am not talking about test automation. I am talking about automating work that should not be done by a tester. For eg, I developed a Screen Capture utility especially for the purpose of test evidence gathering. Another tool I developed was for comparing two XML files (for smoke testing).
2) So that they can put themselves in the shoes of developer. So that they get the same feeling what the developers get when they recieve a bug. This might not seem relevant but this is very important. You have to know how someone feels when you find a problem in their product.
Cheers !!!
Comment lengths are more than your post length.