One thing that I've benefited from in my testing career is that I do have some knowledge of software development coding methods and concepts. While I probably could not code my way out of a paper bag (or at least, not before I suffocate), I can read code and understand what is being attempted.
Is this a good requirement to consider when hiring a new tester or is this just a "bonus" item on a resume?
It depends on what you want your tester to do. I do think it is a skill that is worth paying more money for, but I'd rather have a passionate, skilled tester than one that reads code for most positions. Having at least one tester who can read (and preferably write) code is a very handy thing.
At the one end, you have testers who can use automation tools but can't modify them, but who know what tests will find the bugs and are great at reducing bugs and communicating. Often these testers are very experienced, and can approach a testing problem and break it down quickly. I am fortunate enough to have worked with such individuals, and I learn a lot from them. However, they can only do black-box testing. While there is a lot that can be covered with black-box testing, especially with test-savvy developers who can perform test plan reviews and experienced testers who can often guess at invisible boundaries or perform skilled exploratory testing to find hidden boundaries, there are some things white box testers might be more likely to find.
On the other end, you have SDETs, who are full software developers who apply their skills to the domain of software testing. SDETs will not only test, but will usually develop test tools as well. A tester who codes can write fixtures, automated checks, test scripts and so forth, and can write well-organized, maintainable automated test code. The key downside is that such a tester is also a developer, and gets paid like one. The secondary downside is that such a tester might really want to work as a pure developer, and their testing skill set might be weak.
For the in-between level that you are mentioning, you get white-box testing. Such a tester is someone who can look at the code to identify equivalence classes and boundaries that aren't visible unless you look at the implementation of the code (or have an overly-detailed spec). You might also get debugging, depending on how comfortable the tester is in the IDE. A skilled reader of code might be able to reduce the up-front documentation burden on the developer, by using interfaces to determine the behavior of the functionality, so documentation can be written later in the cycle and testing can happen sooner. A skilled white-box tester could even participate in code reviews and find potential bugs before they are ever coded in, eliminating the extra development and test time that would have been devoted to those issues. Because this hypothetical tester can't write code, however, developers may still need to develop tools for this tester's automation.
The most useful thing I've found since moving from being a developer to a manual/ automated QA position is being able to talk to the developers in terms and language they understand.
The ability to read and understand code is a useful attribute for all testers (in my opinion), and a strict requirement for some tester roles.
But whether it is a good requirement for hiring new testers or just a nice-to-have depends solely on the needs of the specific position.
It depends on the product and the needs of the position. A programming background is obviously useful if the position calls for test automation. It may also indicate a general aptitude applicable for other technical skills, e.g. data analysis. Of course the lack of a programming background does not imply a lack of other technical skills.
I have met testers with a programming background who joined QA as a stepping stone into a full-fledged developer position. There is nothing wrong with that as long as the tester is sincere about doing as good a job in their QA position as they hope to do in their eventual developer position. A tester who has programming skills but who is reluctant to perform manual tests when they are called for, or who is generally unenthusiastic about testing, is a liability.
I do think it can be a bonus on your resume. And depending on what you want to do in testing may be a requirement.
But that said, I don't think it is necessary for all testers. A good test team should be a balance of those who can code & automate, individuals with good domain knowledge and others with great testing skills and background. If you comprise the test team of only one type of employee you end up with a lop-sided team that doesn't do very well. They may automate the daylights out of your software but without domain knowledge could be automating all the wrong stuff.
The main benefit is that a tester who can read code may be able to root cause bugs, not just report them.
Depending on the coding skills involved this may not be true for all applications, but likely would for web applications since it deals with technologies such as JQuery, JavaScript, CSS, HTML, etc. that are sometimes considered to have a shorter learning curve.
As another example, if you know some SQL, you have the advantage of knowing what is written in SQL procedures, keys, joins, etc.
In my experience, it is better to have some knowledge than to have 100% or 0% knowledge.
One risk is that if you have more programming skills, at times you will be distracted by ideas to improve the code and forget your role of finding potential bugs.
In my opinion, not having programming skills won't hurt you as a tester.
In 2011 the right was answer was 'it depends...'
In 2019 I feel that has changed quite a lot. Particularly over the last 4 years (2015-2019)
Every testing position I apply for now has 'automation' in the title or description and every interview I go on is now 'data structures and algorithms 101'. Often at the expense of anything else. I am an automation engineer that writes code but unfortunately the blunt testing of recursion and performance efficiency is very limited in examining the skills of a good automation engineer. I repeated go into interviews with application engineers who openly admit that they have little knowledge of the programming skills essential for automation. The only tools they know is to test skills that are largely irrelevant and NOT skills that are very relevant. Naming and creating high quality (maintainable) code and avoiding premature optimiztion get short shrift if at all.
Much of the the industry has also accepted the 'programming interviews use skills not used much in your real job' (for either automation or application engineers) as something to just accept. I reject it. I was an application developer in several companies before moving to automation engineer and gained this knowledge from that experience. btw there are definitely positions for performance engineers that are good at different skills such as these. They are a minority of positions in my experience.
This trend disturbs me but I cannot change it for everyone.
Basically if you want an automation job, data structures and algorithms are the most likely path to get it. Whether your automation is then successful - and how you measure that - is a different issue.
The biggest advantage I have realized is the ability to understand the code and develop a good intuition. The knowledge of how it is implemented (not actually looking at the code line by line) definitely helps narrow down the cause. Although it is not the necessity for a QA / tester to tell a developer the cause of the bug, it always helps to have an intellectual discussion. This has also helped me gain good respect of a developer. That in turn, helps avoid many unnecessary lengthy discussion or arguments as the developer has a good confidence in the tester.
Effectively saves time. Let's consider an UI based product that is to be tested on multiple browsers. If the tester develops a good understand of the code, he/she may not have to test on all browsers to be confident of the bug e.g. the bug may be because IE doesn't support a particular type of rendering.
Ability to predict the critical modules to test. With time, a good understanding of the product at technical level might help the tester to correctly predict the modules that are more sensitive to break and test those modules before others
Creating and maintaining automation.
Overall reputation - Earning respect because of the depth of knowledge always helps!
It aids if you want to do deep dive/unit level tests, api tests or automation. Understanding code also makes it easier to debug, you know where to go and what tools to use to find the nitty gritty details that make a good bug report and target the fix. It can also open up other roles, doing and maintaining builds, release processes and tools as well as tool smithing for automation or test tools. I've found in small companies have a wide array of skills and capabilities makes you a more respected employee and gives you some "cred" with the developers when you can help them out on tasks so they can focus on coding.
When I started in Test I didn't know how to code, taught myself and learned by asking questions and now its made learning new products easier as I can follow the code much better and understand what it's doing most of the time.
I prefer that my testers understand code and are able to code up whatever is necessary to get a good automation going.
Having said that, I am ambivalent about testers actually reading developer code. In an ideal world, developers and testers should operate off the specs to avoid any contamination of the thought process. Example: Developer puts in hack x in code with comment saying this is a hack. Tester happens to see this, and writes his test around this hack - which usually causes trouble in the long run either way. When the hack is removed, tests break due to unnecessary coupling with dev code / If the hack remains for too long - some features might go untested.
.
One of the main reasons we have testers is the fact that they bring in a different set of ideas to the table. No point in diluting that by making the tester a half dev by involving him in every code review etc. scrupulously. In practice, this gets very hard to implement with a clear delineation, so its better to find a suitable middle ground that works for you.
Think about testing the software where the end user is a programmer or a system administrator. For instance:
In both situations programming, scripting and platform administrating skills can useful well beyond test automation.
Regarding first, I've seen a beta-testing invitation for advanced Python programmers with demanding applications, particularly web applications with databases and AJAX. Testing will require not only testing single APIs, but only build sample applications over it that could stress some aspects of the server.
Regarding second, I've seen an alpha-testing job offer for people proficient with a Unix/Linux environment and other software platforms like AIX, and Solaris. Many problems here may occur in collecting data, thus in integration with platform software.
Definitely testers having a developer background or coding knowledge helps much in software testing but this was long time ago. I think by the evolution of new generation testing tools I don't think that testers no more require to have coding experience as the tools itself has became quite intelligent. This is helpful because I think that if any tester concentrates only on his sole job of testing would more effective as they need not to spend time in tedious coding jobs.
Testing is a full fledged activity which goes in parallel. They are like tracks of a Railway line, going the same direction but not intersecting with each other. It's possible to have QA professionals who are well versed in coding and likewise Developers with a good instinct for QA.
If I were in your place, I would consider dev and coding experience as a plus point but not a mandatory requirement, unless you are short of coders.
