How is it useful to make the distinction between testing and checking? One colleague (let's call him Andrew) recently found it very useful indeed. I've been asked not to reveal his real name or his company, but he has very generously permitted me to tell this story.

He works for a large, globally distributed company, which produces goods and services in a sector not always known for its nimbleness. He's been a test manager with the company for about 10 years. He's had a number of senior managers who have allowed him and his team to take an exploratory approach, almost a skunkworks inside the larger organization. Rather than depending on process manuals and paperwork, he manages by direct interaction and conversation. He hires bright people, trains them, and grants them a fairly high degree of autonomy, balanced by frequent check-ins.

Those of you who can access the BBC iPlayer for radio (is that UK only, I don't know) might be interested in a piece buried in the late night schedules of Radio 5 Live about Boffoonery and Bletchley Park, recorded at the theatre with interviews from myself, Sue Black and the BBC's own Bill Thompson.

I'm getting increasingly vexed by this unhealthy obsession with planning and project management, especially among the Agile community.

The likes of Scrum, Kanban and other variations of the put-stuff-into-some-kind-of-prioritised-work-queue-and-pick-new-work-from-the-top theme have become an obsession to the point that one could be forgiven for thinking that this is what software projects are all about.

The distinction between testing vs. checking got a big boost recently from James Bach at the Øredev conference in Malmö, Sweden. But a recent tweet by Brian Marick, and a recent conversation with a colleague have highlighted an issue that I should probably address.

My colleague suggested that somehow I may have underplayed the significance or importance or the worth of checking. Brian's tweet said,