Chris McMahon is a tester who likes to take a look at the code under the application's hood. Although he has heard that developers and testers alike argue that this makes for less effective testing, he is here to argue that reading and writing code is part of the testing craft and that the ability to read and write code in the service of testing is critically important for the professional tester.
Read the Code
I am a software tester, and I read production code.
I always have read production code. I learned to test software by running code in the debugger. Software developers I have known have argued that this makes me an ineffective tester, since I know how the sausage is made. Software testers I have known have argued that this makes me an ineffective tester, because I'm not behaving like a user would.
I argue that software testers who don't understand code are less effective testers, fail to improve the craft of testing, and probably are stifling their careers.
I started my career reading an odd language called TAL, the proprietary programming language for Tandem systems (now Hewlett Packard NonStop), but it was COBOL that really opened my eyes about how to test software by reading the code. For all its flaws, COBOL is a great language for beginners to learn. It is a procedural or imperative language with libraries and subroutines instead of classes and methods, so the action in COBOL tends to be easier to follow than in more modern languages.
COBOL is designed to handle enormous quantities of data while being readable to reasonable people. Data structures are explicit and data sizes are specified. COBOL is still in wide use in financial and telecom systems, because it remains an efficient way to process immense amounts of relatively simple data. For the tester, this is great: COBOL compilers and COBOL debuggers are incredibly effective, and it is possible to learn an immense amount about the code base using these simple tools.
I read some C back in those days as well. Without going into any detail: COBOL is easier.
When I found a needed to begin writing my own code for testing purposes, interpreted languages were coming into their own. I set out to teach myself Perl, because Perl was the "Internet glue" at the time. I never became a very good Perl programmer, but I learned enough to write some really effective scripts to help me in my testing.
I'm most grateful to Perl for showing me network programming: how to talk to IP networks using various data formats over various connection protocols, all based on low-level IP sockets. It is hard to overestimate the value of this deep, low-level understanding when evaluating errors in networked systems. Also, don't underestimate the ability to surprise programmers by mocking the systems their code is supposed to talk to using an interpreted language like Perl.
Testing the Web
Although I learned my trade as a tester on mainframe systems, it was clear that the Web was the future, and I was deeply interested in Web-testing technologies. When Paul Rogers rewrote Brian Marick and Bret Pettichord's Web-testing tool based on Chris Morris's Ruby IEC library, he blew the roof off the joint. They called it "Watir", for Web Application Testing In Ruby.
Suddenly, we had a usable, maintainable, viable way to drive at least one browser for some really sophisticated testing. I consider Watir the project that really opened the Web-testing field. I switched from Perl to Ruby in order to use Watir, and I've been using Ruby ever since.