Testers are from Venus, Programmers are from Mars

I don't know how this works in other parts of the world, but here in Israel it is very common for wannabe programmers to start with a job as testers. Usually it's some part-time job they do in their last year of studies, with the hope of being appointed a fix job as programmer when they graduate. I didn't go through this path, but many programmers I know have.

My impression from this process, as an outsider who has worked with experienced QA Engineers as well as Software Engineers from various backgrounds is simple - it's WRONG WRONG WRONG!!!

Why?

Well, first, it emphasizes a common misconception that QA Engineering doesn't require specific qualities, something most person with enough brain to eat with fork and knife would be able to do. I think it's degrading one of the most important parts of software development. Being a good QA Engineer is hard, really hard even. It requires specific qualities very few people actually have. When you take inadequate people to do a difficult job - don't be surprised that the results are sub-optimal (to say the least).

Second, I think that there are elementary differences between the character traits required from good QA Engineers and from good Software Engineers. Actually, the qualities required are so contradicting that I don't know any person who would be able to be good at both.

Let me elaborate:

• Patience - programmers are usually rather impatient people. When they feel their computer isn't working well, they'll go poke around the registry and whatever, sometimes making things even worse, just because they don't have the patience to wait for an IT person to help them out. A good tester needs a tremendous amount of patience. They may find themselves doing hundreds of tests, each slightly different from the other, for several days in a row.
• Feedback - programmers like to get immediate feedback, to see results quickly. That's why add-ons like Resharper give you the little green light on the side - so you know up-front your code will compile. Before that, most programmers used to hit the 'compile' button every few minutes, because they want to know - now! Testers can find themselves working on a good release, finding very few bugs. So there is really no feedback for a long time - the fact that they didn't find a bug, is it because the software is indeed so good, or maybe they missed something?
• Ego - programmers are very fond of their ego. We're not like sales-persons, but still, we like being appreciated (hope I didn't offend anyone here...). Good testers are rarely adequately appreciated - if they find many bugs, programmers won't like them (which is a mistake, of course, but that's life). If they don't find bugs, then they inevitably will show up in production, which is even worse. So testers need to be able to swallow their pride often, very often. Something most programmers I know are not capable of.
• Order - finding bugs is not enough. Being a good QA Engineer means you should be able to work in a very orderly fashion, documenting each step in order to be able to reproduce the bug (and give the developer as much information about it as possible). I know very few programmers who are good at this - it's sad, but it's a fact of life we must accept and learn to live with.
• Creativity - both tasks need a healthy amount of creativity. Yet, there is an important difference in the type of creativity required. Programmers need a contructive creativity - finding better ways to build software. Testers, on the other hand, need to find new ways to break the appplication. The difference is subtle, but significant.

I'm sure I'm missing still many other characteristics, but I think the idea has passed. When I think of the really good QA Engineers I know - none of them would make a good Programmer. Same goes the other way - I know of no good Programmer who would be able to be a good QA Engineer.

I strongly believe QA is one of the most important aspects of Software Development. In some sense, it's the most important one - it's the last phase the application goes through before it gets to the clients, the last chance to improve it before you make a fool of yourself. To my great dissapointment, many software companies I know fail to understand this. With companies that are not 100% software (ISPs, networking, applicances, etc.) the situation is even worse - some don't see why they need a QA Team, if they hire good enough programmers...

As I said, QA Engineering is hard. Doing this good is really hard. Finding good QA Engineers is hard. It's important to understand this, and accept it, if you really want your software to be good!

In this spirit I intend to post a couple more posts in the next few days (unless my wife gives birth before I get the chance). I intend to talk about "QA Day" and "Sanity Tests". If you don't know what these are - stay tuned, these are very effective tools for improving the whole development process.