Interview: Brian Marick digs into the evolution of testing

Brian Marick, a longtime professional software testing consultant and founder of Testing Foundations, has a unique perspective on the evolution of test-driven development and its relationship to conventional testing practices.

InfoWorld: What’s the software testing legacy?

Marick: People who understand the problem to be solved — product managers, business experts, customer representatives — produce a grand document [the specification]. Programmers implement it in code. In parallel, testers convert abstract statements into concrete tests. When the programmers produce something, the testers apply their test cases to it, reveal that the programmers didn’t do the right thing, and slap them on the wrists. That’s conventional testing, circa 1960.

InfoWorld: How has the test-first movement influenced professional testing?

Marick: The requirements document is written by people who are no more infallible than the programmers writing the code. So the notion arose that by writing tests immediately, the effort of making things specific could uncover bugs in the document and clarify and improve it. Of course, there was the fear that if programmers knew the tests in advance, they’d write code to pass the tests. I met one guy, a Beltway bandit, who was proud of the fact that he did exactly that!

So the test was only a reactive mechanism to the real thing: the document. Now people are saying the tests aren’t just a reaction, they are often the thing you have, the thing that drives development. In fact, the two work together. We are learning to write tests that help the programmer to write the right program. The requirements doc and the tests share a common goal: to provoke the right kinds of conversations among developers, managers, and customers. But they achieve it in different ways.

InfoWorld: You’ve described the evolving role of a testing function that’s separate from programming, but don’t these roles converge in the test-driven approach?

Marick: Practically speaking, the writer of tests and the writer of programs should be the same person. It’s true that person can make the same conceptual errors writing tests as code. But we don’t live in a perfect world, and separating those functions incurs a huge cost in communication overhead.

InfoWorld: Are some people better suited to the test-first style than others?

Marick: People who like examples are attracted to test first and are successful with it. “Show me what this does,” they say. “Oh, it takes this and this, and produces that. OK, I get it.”