When it comes to the increasingly important role of test developer, hiring managers have a choice to make. They must decide what is the controlling criteria for hiring. Which is more important, testing skills or development skills? Sure, you want both to be strong but often times, you don't get a perfect candidate and are forced to compromise. If you have to choose one skill as the more important, which should it be? There is no universal answer. Each situation will vary. However, it is my assessment that you are often better off hiring a good developer and teaching testing skills rather than hiring a good tester and trying to teach development skills. The reason for this is largely this one belief: it is easier for the average developer to learn to test than for the average tester to learn to develop.
When I say developer, I don't just mean someone who knows the syntax of a programming language but rather someone who really understands programming. That is, someone with computer science competencies. This is not necessarily someone who has a CS degree. The person can be self-taught, but they need to understand the sorts of things computer science students learn. They need to have familiarity with data structures and algorithms. They must understand complexity issues. They should be familiar with operating system concepts including concurrency. For a modern programmer, experience with object-oriented design principles is also necessary.
Two critical traits all testers must have to pay attention to details and being curious. A tester needs to be thorough. They cannot afford to leave any stones unturned in their quest to explore the product. Good testers also need to be curious. They need to have an instinct where to look to find the issues. They have to want to experiment.
Let us think about most developers. Are they detail-oriented people? The good ones are. Code is unforgiving. If you don't pay attention to details, your program will misbehave or even crash. Are they curious? More often than not, curiosity is what brings someone into programming. Is it the sense of exploration and later mastery that drives most of us forward. It would seem then that good developers have the basic traits to be good testers.
What about the average tester? Here I'm not talking test developer but rather someone who is less skilled in programming. Do they have what it takes to make a good developer? There is no way of knowing. While curiosity and thoroughness are traits most developers have, those are not sufficient traits to be a good programmer. To be the best programmer one must be a good problem solver. One must also be able to think in very abstract ways. Most good testers are also good problem solvers. However, I'm not convinced that there is a correlation between abstract thinking and testing. Testing can be done in a very concrete manner. Many who make good testers do not have the ability to become great programmers. It is often this trait that is missing.
Now let us consider the specific skillsets required for testing and programming. It is argued that testing is just as difficult as programming. That the skillset required is equally deep and varied in manner rather than scope. I reject this notion.
It's not that I think testing is easy. It isn't. I've interviewed many people who don't have what it takes to be a good tester. They have the wrong mindset. They aren't curious or thorough enough. Sometimes they just don't really grok computers. Often times the higher level skills in testing are enumerated to prove the difficulty. These include things like understanding equivalency classes or pairwise testing. The thing is, I've never found these to be too difficult to understand. Equivalency analysis--despite its fancy name--is something any competent tester should just intuitively understand. Pairwise testing is more complex but is something any CS student should be able to understand quickly. There is a lot of art in successful testing too. This can take a long time to develop well. The average developer isn't going to be a great tester overnight.
How about programming? How easy is it for the average tester to pick it up? As I argued above, good programming is not just knowing the syntax. I like to use the concept of writing to prove my point. Knowing the syntax of a programming language is like knowing grammar. You can correctly form sentences and can most likely convey your point to the audience. However, knowing grammar does not make you a good writer. What sets Mark Twain apart from your typical math student is not just a superior knowledge of grammar and vocabulary. It is understanding the larger process at work. Likewise, knowing the syntax of C++ or Java doesn't make for a good programmer. One merely needs to watch The Daily WTF for a short while to understand why such thinking can cause enormous trouble over time. It takes a long time and a lot of hard work to go from being someone who understands syntax to someone who can truly weave code.
Thus I think the gap between a tester and a developer is harder to cross from the tester side than from the developer side. A developer can become an adequate tester well before a tester can become an adequate developer. Given the choice between someone who is a good developer and someone who is a good tester and each lacking much skill in the other discipline, I'll take the developer nearly every time.
As always, your mileage may vary. There are some testers who go on to make amazing developers. There are developers who cannot grok testing. There are some jobs where you don't really need good development skills. Sometimes a person who understand syntax is enough.
That's my take anyway. Release the arrows.
A few related articles are Chris McMahon's discussion of developer-testers vs tester-developers. Also Elisabeth Hendrickson has a great post about the convergence of testing and development.
PingBack from http://blogs.msdn.com/steverowe/archive/2007/01/15/hiring-great-testers-series-index.aspx
ReplyDeleteSo do you hire developers and then convince them to turn to testing ? or do you hire testers and test them on their development skills at interview time ? What do your job ads look like - "tester with development skills required " ?
ReplyDeleteI somewhat disagree.
ReplyDeleteTeaching a developer to test might well prove to be impossible -as you mention yourself ,not everyone can test. at least not well.
Actually some say that some very different thinking attitudes are required from dev and from a tester...
For me, it's always been a curiosity about how the software was constructed, not necessarily a curiosity about how the software manifests itself in the world.
ReplyDeleteMy very first week on my very first computer job, I was taught to use the debugger. I spent about half my career reading code before I ever wrote any.
I have a read a LOT of code, some great, some awful, most pretty good. I'm sympathetic to the compromises developers sometimes make.
I am not a great UI tester, nor am I great developer. I like to work closely with both of them though, that seems to be good synergy.
Some of the best testers I've worked with could not program, and had no interest in programming. Some of the worst testers I've worked with were programmers. My conclusion? Like everything else in life, it depends.
ReplyDeleteEffectiveness depends on the person and their ability and interest in testing, which is why I like test teams with both programming testers, and testers with other skills. The other kinds of skills can be a breath of fresh air, and can lead to unorthodox ideas that are effective.
If a non-programming tester has no testing skills, and no programming skills, I wonder what they can offer. Not all non-programming testers are like this though.
Here's an example of diversity of skill at work. I was looking at how to test communication between two systems. I immediately looked at the problem from a technical perspective, and read code, looked at the interfaces and mapped out what technology and libraries were used, and looked for points of failure. I primarily used programming tools for my investigation.
A non-programming testing colleague of mine brought in a book on communication - one of those psychology books on human communication. She used typical communication breakdown patterns as a place to start failure modeling.
The result? We were both surprised at the others' findings. My programming-centric view was much narrow, and her communication-centric view missed out on some details. However, together, the combination of testing ideas was amazing, and better than we could do on our own.
The programming fixation with testing misses out on a lot of great ideas, and I will defend skilled non-programming testers on a project as vigorously as the programming testers. :)
-Jonathan
@Phil - For an SDET job, I hire programmers and ask them to test. I've had quite good luck with it so far. I find hiring a (non-programming) tester and asking him/her to program is a lot more work. Obviously the best is to get a programming tester but there aren't a whole lot of those looking for jobs.
ReplyDelete@akulpuko - I agree. There are some who can't learn. Most, however, I've found can. It's easy to screen out most who really can't in an interview with a few test questions.
@Jonathan - Very good observation. There are different perspectives brought by different people. Those who code tend to have a particular view of the world. It would be a bad idea to exclude them from the process. I've always been a big advocate of having what I call "runtime testers" on most testing teams. This is just one more reason to do so. Note that this essay is specifically about test developers though. If I need something automated, I don't know if I'd want this woman with the psychology book doing the work. I'd rather try to teach a developer to look from another perspective than to try to teach her C++.
"If I need something automated, I don't know if I'd want this woman with the psychology book doing the work. I'd rather try to teach a developer to look from another perspective than to try to teach her C++."
ReplyDeleteI'd rather have them work together. I don't think I can teach the programmer her skills any more easily than I can teach her C++. Working together, the test designs are going to be that much stronger as they each play on their strengths and interests.
-Jonathan