Not seeing the wood for the trees

Four of us presented a seminar on the techniques we have been using to test the product: JUnit, EclEmma for coverage, Selenium and a random spider for web UI tests, checkstyle for static checking.

One person reported that we had found that the javascript validation did not work just hours before a release. "When I saw the panic ... I swore I'd make tests from now on."

One said that by personal experience, he "spent half his time on defect fixing before, but now" that he uses Test Driven Development "it is only 20% of the time".

One reported a time when I had deferred a fix until the next release, and said that this did not correspond to the users' priorities.

So there were a few gems in it. But it was also significant that their presentations were overwhelmingly on details of the tools, not of how using them changes the development process.

We are half way through a five year project. It's time to think about preparing them for their next roles. How can I encourage them to abstract from the day to day work and become conscious pilots of the project?