Share via

Brian Marick on "Undoing Testing in Agile Projects" from the XP/Agile Conference

  • Article

Brian Marick brings a unique perspective to agile development projects. I have found his website https://testing.com to be an invaluable resource and I also read his blog on a regular basis. Brian gave one of the keynote addresses at the XP/Agile Conference this week.

Some interesting points included:

  • Unit Testing and programmer focused test-driven development has crossed the chasm from the visionary stage to the pragmatists. For detailed information on the chasm terminology see “Crossing the Chasm”, by Geoffrey Moore. Brian supported this statement with the following reasoning:
    • Universities are teaching test-driven development. This often follows the visionary stage and it does help to reinforce the technique because when the students graduate they already know the technique.
    • Tools are appearing to support the technique. He gave a number of examples.
    • The appearance of second wave books. For example, JUnit Recipes by J.B. Rainsberger
  • The other TDD is still in the visionary stage. This is defined as tests being used to drive the behavior of the system. Brian calls these examples or story-driven design instead of tests. In traditional XP terminology these are acceptance tests and XP talks about these tests being done by the on-site customer or a representative of a number of customers.
    • One of the issues Brian spent a fair amount of time talking about is that customers are really focused on describing business value. Often, they are less focused on avoiding business loss. If you don’t think about these things then you leave gaps in the system.
    • Another issue is what he referred to as the Agent problem. It is almost impossible to act as an agent for someone without being captured by one of the special interest groups that are being represented.
    • The last thing which I though was an incredibly useful suggestion was to have the customer describe an example of the how the system should work. The tester on the project should use that information to write a test and then go back to the customer with the test in hand and determine if the test is what the customer had in mind. This gives the customer and the tester an explicit focal point for furthering the conversation.
  • Another suggestion from the talk that I plan on using at the end of the next iteration is the following:
    • Demonstrate the features to the customer.
    • Have the team spend a short period of time using the newly created features as the customer would use them to see how they really work.

All, in all I thought it was a great talk.

Comments

  • Anonymous
    August 17, 2004
    Sounds like one! I wish I could have been there... :)