Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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?

share|improve this question
    
I think there's plenty of people like this: some specific coding skills, lots of nonspecific technical and "soft" skills. Some of these people would make outstanding testers, so this is a great question! –  joshin4colours Aug 17 '11 at 14:15
add comment

11 Answers

up vote 7 down vote accepted

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.

share|improve this answer
    
This is the best answer of the ones provided because it gives a good description of the pros and cons of testers that can read code and some practical examples of them. I like @Joe's answer as well as it does mention that code understanding is a requirement for all testers. –  TristaanOgre May 20 '11 at 17:10
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
+1 for the tester who doesn't want to perform manual testing at need being a liability. Not everything can or should be automated, and those features need to be tested as well. –  Kate Paulk Aug 17 '11 at 10:40
add comment

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!

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
While I agree on the contamination point, I think it is helpful for a tester to know at least some of the logic that's in the code that s/he is testing in order to be able to build boundary cases and the like. Additionally, while the tester doesn't need to read the actual code to do this, having some knowledge of what happens when you don't initialize a variable, what happens when you loop on n-1 records on an array based upon 1 instead of based upon 0, etc., is helpful in, again, knowing what kinds of tests to run and how to communicate results to the developers. –  TristaanOgre May 17 '11 at 16:48
    
Additionally, as @Ethel points out below, the ability to help out with static white-box testing (code review) is VERY helpful to give that other pair of eyes to things –  TristaanOgre May 17 '11 at 18:09
    
Ideally all these information should be arrived at from the interface, not by looking at the implementation. And the other pair of eyes are your other developers in the team :). In fact, the other developers will have a better understanding of interactions with other related components internal workings as well - so this will help them give better comments. –  Subu Subramanian May 17 '11 at 22:48
    
The interface does not necessarily indicate what the code path is. I have a project I'm currently working on where that is the case. There's a fairly complex decision tree made to determine who gets e-mail notifications of certain events. However, the interface is simply a data entry screen. Now, there are detailed specifications, but there are some complexities in the decisions that a specification is VERY verbose on but can be easily summed up by looking at the code. –  TristaanOgre May 19 '11 at 14:10
    
Interface need not be the HCI alone. Testers usually write code at all interface levels - interfaces between classes etc. This is where whitebox testing comes into picture. In your case, this should solve the problem - again, as long the SRP and interfaces are clear. –  Subu Subramanian May 23 '11 at 8:45
add comment

The benefit is you will not just report bugs, you tell the cause of the bug. Again this will not suit for all kinds for applications. But this will work well for a web applications since it deals with jquery, java script, css, html etc. Again when it comes to SQL, you have the advantage of knowing what is written in sql procedure, keys, joints etc. To my experience it is good to have a little knowledge than being 100% or 0%. If one dont have that little knowledge, he could gain it easily.

Risk: the risk here to be more programming is, at times you will look on codes to improve it and forget your role about getting potential bugs.

Verdict: it will not harm you, if one doesn't have programming skills.

share|improve this answer
add comment

Think about testing the software where the end user is a programmer or a system administrator. For instance:

  • Application server that you configure and build applications over.
  • Tool for managing and monitoring distributed system infrastructure.

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.