Matt Heusser interviewed Gerard Meszaros for InformIT recently. Here is the article, but here are the quotes from Gerard’s answers that really stood out for me.

  • I think of the automated unit tests (and automated story tests) as “bug repellent” rather than “bug detection.” Traditional testing is about finding bugs while automated unit testing, done in conjunction with Test-Driven Development, is all about preventing the bugs from happening.
  • A lot of the techniques I describe can be applied to para-functional tests such as load and performance testing.
  • Exploratory testing by definition cannot be fully automated but testers doing exploratory testing can use automated test tools or scripts to help them execute the tests they define on the fly. – just to reinforce this, this is one of the main reasons why I think testers should learn a scripting language.
  • All techniques have limitations, especially when they are abused or overused. The biggest hazard with automated unit testing is writing tests that are hard to understand and which are therefore hard to maintain as you evolve the code.
  • C should be tested even more thoroughly than Java or C# because the compiler won’t catch as many mistakes! Likewise for dynamic scripting languages like Ruby or Perl; it is easy to introduce bugs that will only be found at runtime, so running all the code regularly via automated tests is crucial.
  • To me, the ultimate measure of the quality of the test code is how easy it is to read, because it will be read a lot!
  • Personally, I subdivide tests based on the kinds of characteristics we are verifying (functionality, para-functional qualities) and the granularity of the system under test. So I have functional unit tests, component tests, system tests, and workflow/integration tests. Acceptance tests and regression tests are just two particular uses of any one tests at different points in the lifecycle of the code.