Five Questions With Brian Marick

Brian Marick has done it all: Programming. Testing. Managing. Testing consultant. Long about 2001 he dove into Agile, so much so that he was one of the authors of the Manifesto for Agile Software Development and has served as chair of the board of the Agile Alliance. These days he calls himself an Agile consultant and advocate. He hasn't forgotten everything he has learned about testing however, for those learnings shape his Agile work in many ways. Here is what Brian has to say:

DDJ: What was your first introduction to testing?
BM: It was 1981, just around the time TCP was introduced. I wanted to write networking software. My first boss said, "We really don't know how good you are, so we're going to put you in testing. At least there, you can't do any harm."

DDJ: What did that leave you thinking about the act and/or concept of testing?
BM: Well, first, that I needed to "graduate" from testing and get to my real work, programming. In those days, a lot of testers were either new hires on probation or programmers who hadn't made the grade.

That was the bad part. The good part was that I was assigned to test the code of a star programmer. I found 60-some bugs ("can't do any harm", indeed). That left me with the conviction that I could look like a much better programmer than I was, provided I tested my code well. That turned out to be true - except that today I wouldn't say I "looked like" a better programmer. I'd say I really *was* a better programmer.

DDJ: How would you describe your testing philosophy?
BM: Nowadays I focus on testing in Agile projects. They still need after-the-fact, product-evaluation testing, though I'd focus it more on testing "ilities" like performance, security, and usability.

I am no fan of having people repeat tests by following scripts. You might need a few of them, but the vast majority of repeated tests should be repeated by machine (that is, should be automated). If the tests are too expensive to automate, you most often (1) have programmers who don't care about testing, (2) have lousy relations between the testers and programmers, or (3) are automating wrongly. It's better to fix those problems than patch them over with scripted manual tests.

I'd want manual testing to be free-form and exploratory. And I'd want some exploratory testing no matter how good our automated test suite is. Writing automated tests puts you at a remove from the program: you're writing *about* using it, not using it. The act of putting hands on opens up a different kind of imagination -- we're tactile animals, after all -- and lets us notice and exploit oddities.

But Agile projects open up more opportunity for testers. Agile projects almost always reject requirements documents or rigorous specifications. Among their other problems, those documents are way too abstract. Abstraction is swell for identifying and concentrating on what you know or suspect is important, but they let you skim over what you think are irrelevant details.

*Examples* are good for revealing that irrelevant details are really relevant, or that two people who seem to be agreeing on the meaning of some abstract term are in fact disagreeing. For that reason, I have a sticker on my laptop's lid that says "an example would be handy right about now". In meetings that seem to be bogged down or skipping over something important, I hold up the laptop and repeat the slogan. Even better is when someone else points at the laptop and says it before I do.

A test is an example of how the product should work. So one of the tester's new jobs is to be part of product definition conversations and make sure there's agreement on concrete examples, not just on vague statements. And then make sure the product is exercised against those examples when it's built.

DDJ: What do you think is the most important thing for a tester to know?
BM: I don't know what's most important, but I've come full circle on the matter of automation. In the 80's, I thought it was ridiculous for tests not to be automated; therefore, all testers should know how to program. In the 90's, largely due to the influence of Cem Kaner, I came to realize the power of exploratory testing and how often automation was a waste of money in comparison. In that decade, I was accused at conferences of being "against test automation." That was a wild exaggeration, but I definitely erred on the side of manual testing.

Now, in the naughts, I'm back to favoring automation. That's because of three things. The first is the popularity of testing among Agile programmers, which means that they write far more testable programs. The effort to automate is much lower. The second is the availability of tester-friendly languages (my favorite being Ruby). Compared to the C of my day or the Java/C# of today, these languages make automation much easier. The third is the way Agile programmers depend on tests to guide and pace their programming. That means a test isn't useful once a month, when the programmers drop a new test build on the testers; it's useful from day one as the programmers run it over and over as a part of writing their code.

If you'll permit me some self-promotion, I'll mention here that my book Everyday Scripting with Ruby has just been published. Testers are the main audience.

DDJ: What do you see as the biggest challenge for testers/the test discipline for the next five years?
BM: For testers to influence the project the way they should, they have to be able to write tests that (1) can be understood by non-technical businesspeople so that they can be part of the project-long design discussion, (2) don't require programmers to write a lot of support code (that is, not more code than they write to support their own unit tests), and (3) are easy to edit, so that they can evolve as the product does.

The tools to support that are inadequate. Even if they were, we have a lot to learn about how satisfy the businesspeople, the programmers, and the changing program, all at the same time.

Posted by The Braidy Tester at 07:30 AM  Permalink