How much programming knowledge does a tester need?

[Harry Robinson]

Greetings TD-DT'ers!

 

I'm always encouraging testers at my presentations to learn to program. As I mentioned at the Summit, I think the era of the non-programming tester is coming to a close. In many high-tech companies, it has already ended. At a presentation a few weeks ago, someone asked me what they should learn about programming to be a better tester. I didn't have a ready answer.

 

So, I've been thinking about it. I think all testers should know something about programming, but how much and with what kind of focus? Rudimentary scripting knowledge is needed for even simple test automation. Advanced testing practically requires that you be able to program well. The issue is that tester-developers have a different focus than developer-developers so it seems reasonable that a tester learning to program should follow a different path.

 

For instance, many developer-developers love optimizing code, and that's good: fast code can an important factor in a product's success. But optimization is rarely an issue in test code since the performance requirements are not as tight. I'm not advocating dog-slow test code, but I prefer that test code be as simple as possible so that it stands a better chance of being right. Then testers can find bugs based on the differential between the fast-and-possibly-complex SUT and the not-as-fast-but-simpler test code.

 

So, how much programming should advanced testers know? Basic programming is a shoo-in. Advanced optimization sounds like overkill. Data structures seem like a gray area.

 

I'd be interested to hear your thoughts.

 

Thanks,

Harry

 

[Chris McMahon]

> So, how much programming should advanced testers know? Basic programming is
> a shoo-in. Advanced optimization sounds like overkill. Data structures seem
> like a gray area.
>
> I'd be interested to hear your thoughts.

Two things:

First, there is a great interview on Pat Eyler's blog with Brian
Marick about his new book, where he talks about this. Here's a little
quote, there is a lot more here:
http://on-ruby.blogspot.com/2007/01/author-interview-brian-marick.html

"What kinds of scripts do testers write as opposed to other kinds of
programmers? Can you give us a short example?

Brian: I think you'll find proportionally more scripts that set up big
piles of data. Some scripts drive programs, but in an interesting way:
they move the program to a particular point where a manual tester
takes over for some exploratory testing."

For myself, I have a particular hobbyhorse I've been riding for some
years now. I think that, using the languages(s) of their choice,
testers should be in a position at any time to address

the filesystem
the database
the network

Meaning that it is likely that you will have to find, open, read, and
parse files, so you should know how to muck around with large numbers
of files, use Regular Expressions on their contents, etc.

The data you need for testing will not only be in files, it will be in
databases. So testers should know ODBC and other connection schemes,
and a fair bit of SQL, and also learn tricks like treating CSV files
as tables, scripting Excel, things like that.

Finally, testers should be able to send and catch messages with common
network protocols like HTTP, SMTP, FTP, telnet, etc. Socket
programming is useful in some cases, and should also be part of the
toolbox.

There are a lot of testers without this knowledge. But those who
have these basic skills I think are not only prepared to go a long way
in their testing careers, but are also in a position to get the
respect of developer-developers.
-Chris