More Tester Exploration
A few days ago, I began a verbal exploration of testers who code and coders who test. That post provides some context for today’s continuation, so if you have a moment, go ahead and check it out.
OK – I know you didn’t read it (or you read it already), so I’ll give you the summary. There are coders, testers, coders who test, testers who code, and many variations in between. If it’s good for a coder to have some test knowledge, it certainly can’t hurt to have some knowledge of code if you’re a tester. My contrived exercises asked you to consider what mix of testing and coding knowledge you’d pick when staffing a team. The spectrum of awareness and infusion of coding and testing skills looks a bit like this:
But that’s not (as some of you pointed out) the full picture. I know fantastic testers with tons of experience and the ability to find the the most important issues quickly and efficiently – but they’re jerks (and that’s putting it nicely). It doesn’t matter how awesome you are, if you’re a horrible teammate, I don’t care.
it’s been 35 years or so since I played any paper based role playing games, but when I did, we had these “character sheets” where we kept track of our characters stats and experience. Something like that would give a lot better picture of the full picture of a good software developer.
It’s not perfect, but it helps to see the big picture (and I’ll be the first to admit, it’s difficult, if not impossible, to measure people on a scale like this) – but as a leader, you can certainly consider the type of people you want on your team. You can’t just hire the first code-monkey (or “breaker”) you find and expect to have all of your problems solved. When I make hiring decisions, those decisions are based an itty-bitty bit on whether the candidate can do the job, quite a bit more on how they will fit in with the team, and a whole lot on how well I think they’ll be able to help the team months and years down the line.
And with that, the intro to this blog post has turned into an interlude, so I’ll wrap this up later this week. Great discussion so far (in comments, twitter, and email) – please keep it up.
I can’t fully agree with you on “it certainly can’t hurt to have some knowledge of code if you’re a tester” – as it probably make you a bit biased to how you would expect things to work,
But I would agree that the benefits probably overcome the downsides.
Just as having all the work being done by testers experienced in the application technical field (or by automation) may lead to neglecting test cases where user has made mistakes, and these leave some leftovers which cause a fault later on.
(most of the time when one comes to “Reuse” that object)
Experienced people hardly make mistakes – but normal users often do.
@halperinko – Kobi Halperin
You are not the customer.
Period.
You’re part of the development team, and any notion you have that knowledge of tech somehow influences your ability to “act like the customer” is a myth. At least that’s what I’ve seen in my experience. You’re welcome to supply any data to the contrary.
Beyond that, it’s important to note that “code knowledge” doesn’t necessarily mean “test automation”. It means that automation may be an option, or maybe it’s analysis or monitoring tools, or batch file deployments or windows scripting to accelerate test setup or …
My answer (which is based on my experience) is “it depends”. It depends on many factors which can form another (long) discussion.
I am not sure testers can keep being not code aware forever, but the best programmers I know are also test aware.
Test automation is a different story. To be any good at it you have to know how to code (at level which is again “it depends”).