Five Questions With Keith Braithwaite

Keith Braithwaite is hard core about doing good work. As a Principal Consultant with Zuhlke, he works with teams to help the do the good work they know they are capable of yet do not know how to achieve. One example I particularly like involved building a system to autogenerate trades. While trading systems are complicated in and of themselves, this particular system had to negotiate banking calendars for many different countries in order to determine when and where particular trades would be valid. The development team had mired themselves in a marsh of messiness as they attempted to codify the rules for this system. Keith helped them make their way out of this swamp by having them define examples of the rules rather than the rules themselves. This approach worked well - so well , in fact that no defects have been reported since the system entered production!

Keith was an early adopter of Extreme Programming and Agile and has learned lots about how to succeed (and fail) at adopting these practices for everything from line-of-business applications to embedded software. For the last several years he has been passing along his learnings to the rest of us in the form of blog posts, papers, and presentations, including several talks at the recent Agile 2008.

Here is what Keith 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?
KB: In my second programming job I was lucky enough to work for a guy called Rob Whittick, from whom I learned a great deal about many things. Rob has a skeleton test framework that he carries around in his head and regenerates at each new place he works (I think the original was in Pascal, we used C++). Anyway, Rob insisted that we programmers write automated tests for every function in every class as we went along and run them at every available opportunity. This did all the good things for us and our code that one might expect. What sticks in my mind, though, is that the tests took on a life of their own and became the way the system was explained to people, up to and including paying customers. This was well before I had heard about any of this "Agile" stuff.

DDJ: How would you describe your testing philosophy?
KB: I'm a very firm believer in test-first and test-driven. Both developers writing unit tests before coding, and users writing acceptance tests (these days "checked examples") before the developers start. I'm developing my thinking on this all the time and my current notion is that passing tests are not best thought of as weak evidence that a system is defect-free (as per Dijkstra's comment) but rather as strong evidence that it does in fact have the specified features. I've come to think of test-first users tests as like the go/no-go gauges that machinists use to quickly check if a piece is in tolerance without actually measuring it.

DDJ: Is there something which is typically emphasized as important regarding testing that you think can be ignored, is unimportant?
KB: I'm going to go out on a limb and say: finding defects. We are learning much better ways of not letting defects get in in the first place (or re-discovering how to make old ones tractable), which is much cheaper. Through the influence of the technical practices that come with Agile, testing is turning into something else, something more valuable and more enjoyable.

DDJ: What do you see as the biggest challenge for testers/the test discipline for the next five years?
KB: Testers have a huge opportunity and a huge challenge at this time. In Agile practice (the way I do it, anyway) we bring testers to the font of the process. We make them the user's friend and aid. Their job is to help the paying customer back the programmers into a corner from which they cannot escape without building the system that the customer needs. And to help the programmers by getting the customers to write down the problems they want solved, rather than their hallucination of the solution they think they'd like.

There is still a role for testers who shake the built system really hard to see what falls off, that must continue. What many teams are finding is that those same skills of asking the awkward questions, finding the edge cases, provoking the unexpected response are at least as valuable as part of requirements engineering than they are in hunting defects. To win these benefits testers need to change their behaviours and overcome many decades worth of bad industry habits surrounding their role. In particular, testers need to push harder for designing in testability, and get involved at the very beginning of any development effort. Testers need to get themselves on board and intimately involved from day 0.

DDJ: Going meta (to channel Jerry Weinberg), what else should I ask you? What would you answer?
KB: You should ask me "where do you see testing making the greatest contribution to development projects?"And my answer is "everywhere". Write tests to capture requirements. Count tests written to measure scope. Count tests passing to measure delivery. Use tests to drive design. Use tests to communicate between teams, with customers. Use tests to meet regulatory loads and show compliance without mountains of paper. Oh, and to find defects too. But that last one is just the cherry on the cake.

[See my Table Of Contents post for more details about this interview series.]

Posted by The Braidy Tester at 07:30 AM  Permalink