Five Questions With Joe McMahon

Joe McMahon has been involved in software development for almost thirty years. Back in 1979 he worked on satellite ground communication systems for NASA, eventually moving into IBM mainframe systems programming, Unix system administration, and earth science web applications. Then he moved to Yahoo!, where he has worked on test automation and is currently writing developer tools. He has done a bunch of Perl-related work as well, including enhancing the core test suite and documenting the Perl debugger. And now he's learning how to write audio software for OS X - which plays well with his other hobby of playing keyboards.

Here is what Joe has to say:

DDJ: What was your first introduction to testing? What did that leave you thinking about the act and/or concept of testing?
JM: I fell into testing myself quite by accident. I was at OSCON, and Michael Schwern was doing a session on Test::More - a nice automated testing module for Perl programs. Long before the end of the session, I realized I was missing out on a great technique. I already knew that more automation meant more work done, but automating testing opened my eyes to the idea that not only could I get more done, but I could be more certain that it was going to work, and that once I'd fixed bugs, I could ensure they stayed fixed. Suddenly I had a lot more time. I felt free and empowered.

DDJ: How would you describe your testing philosophy?
JM: Any testing - as long as the results are dependable - is better than no testing. If you can demonstrate that testing will save them time and embarrassment, they will go from uninterested to enthusiastic.

Testing early is always better than testing later.

DDJ: Is there something which is typically emphasized as important regarding testing that you think can be ignored, is unimportant?
JM: The idea that not writing all your tests first somehow makes your testing less valid. The only real metric that applies here is that as long as you are testing, you are doing the right thing. Turning testing into something with things to feel bad about not doing is a sure way to discourage oneself. Do tests. They don't have to be pretty, or perfect. They only have to be dependable.

DDJ: What do you think is the most important thing for a tester to know? To do? For developers to know and do about testing?
JM: For testers, that testing is always a search for the balance between the amount of effort expended on testing and the necessity to say "good enough, let's go with it', and that sometimes you're going to have to be unpopular and say "we haven't done enough yet" despite tight schedules. For developers, automated tests always have to pass. You can't get information from a test run if you have to decide whether or not failures are "significant". If they aren't, mark 'em as TODOs. If they are, well, fix 'em!

DDJ: What is the most interesting bug you have seen?
JM: My favorite one has to be Trey Harris's 500-mile email limit. The story's at http://www.ibiblio.org/harris/500milemail.html for anyone who hasn't read it. It's a beautiful description of assembling the data, testing, and getting that one idea that brings it together and solves the bug.

Posted by The Braidy Tester at 07:30 AM  Permalink