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.
http://blogs.msdn.com/b/steverowe/archive/2007/02/13/hiring-great-testers-how-important-is-testing-affinity.aspx
No hay comentarios.:
Publicar un comentario