For a while, I've been trying to describe how I work... how I coach teams... Or at least how I have been for a while now anyway. I've said things like "I focus on values not practices" or "I help people understand what they want to achieve then help them find ways to achieve it"... or "I help teams ask questions of themselves that, with the benefit of hindsight, I would have asked myself". However, after reading Jason Gorman's post I realised that, completely by accident, I was doing much the same thing. Jason says:

Instead, I finally admitted that my real job is to persuade people that they want to learn. And not in any bulls**t manipulative way. I've focused the largest part of my effort on being a catalyst to help recharge people's interest and passion for what they're doing.

For anyone interested, I was interviewed after giving my "Behind every bug is a story" tutorial at STAREast. This interview is now available online.

Joey McAllister speaks with Antony Marcano about his STAREAST tutorial, "Behind Every Bug is a Story," as well as some of the other conference sessions that Antony attended and enjoyed.

The short answer is "no".

Several people have found my explanation of it useful so I'm sharing it here...

The QA metaphor in software development has come from other, arguably, more mature industries - such as medicine, manufacturing, construction and so on. It is about all the things that we do to increase the probability of building in quality - not just detecting when we've failed to build in quality as is the case with much software testing. In this regard, testing is more analogous to quality control or, QC.

In simple terms:
QC helps us answer the question 'does our product work?'
QA helps us answer the question 'does our process work?'

Unfortunately, many teams don't realise their process doesn't work until the testers find all the ways in which the product doesn't work... maybe that's why software testing has come to be known as QA.?

It's true - people who don't get TDD hear the word 'Test' and all but ignore the 'Driven Development' part of it... sometimes to the point that they assume "oh, that's that testers job then"... or the opposite happens when you hear "doesn't that mean developers spend time testing when they should be writing code?"... It can take long and hard to break through this initial cultural barrier... For a long time I've searched for a way other than dropping the word 'T' in 'TDD' to break through the inevitable barrier and I'd almost given up hope... to the point where I was about to resort to the BDD philosophy. The benefits of test-infection made me persist.

To try to get people to understand the 'Driven Development' aspect of writing customer tests first a.k.a. "Acceptance Test Driven Development" (ATDD) and the relevance of the test and testing and testers and let's not forget early and frequent customer feedback... I've been using a different approach. It doesn't solve all of the problems caused by the letter 'T' but it does solve one of them - the part where people ignore the fact that the tests are driving development (yes I said 'tests' not 'testers' - I emphasise this because someone recently asked me 'so, how exactly do the testers drive the developers?').

So... let's talk about something else for a second... I want you to stop thinking about testing... for one moment. I want you to forget about the word 'test' and all the connotations that go along with it... I want you to think about something else... something random... let's say... 'Internet Radio'...

I'm not sure why it is called hackontest, nor am I sure why the definition of 'hacker' used on their website highlights the 'clever programmer' aspect of its origins but ignores the 'learning programming by trial and error' (i.e. not necessarily knowing about designing for maintainability and other such things)...

But, they have a goal to advance one or more open source tools by having a day dedicated to adding new features to open source tools...

The Swiss Open Systems User Group /ch/open organizes the first international Hackontest sponsored by Google as part of informatica08, the Swiss year of computer science 2008. Hackontest is a 24-hour programming competition of three teams of different open source projects. Its goals are to enhance popular Free Software projects according to user needs and to demonstrate to the public how enthusiastically open source software is being developed.

Interested in proposing a project? Interested in voting for features? Interested in competing for the USD 8500 prize?

Well - if you are, check out the Hackontest website for more info...

Tomorrow (Tuesday 15th April 2008), I'll be at Extreme Tuesdays Club at the Counting House.

If you want to chat about testing on Agile projects, Test Driven Development or just like beer and pie then do come along.

When I hear debates about scripted vs. exploratory testing... or even debates such as "automate all tests" vs. "you can't automate all tests"... I don't think I'm hearing the real debate.

I think the debate that I'm hearing is "testing is about confirmation" vs. "testing is about discovery".

This distinction in the underlying intent of a given approach seems to not be emphasised in these discussions.

In simple terms, I think of the intent behind testing as having two facets:

• Confirmation - Does the system do what we anticipated it should do?
• Discovery - Does the system do (or not do) anything we did not anticipate it would (or should do)?

In a recent post from Jason Gorman he discusses how some people drop the word 'Test' from Test-Driven Development.

I feel their pain... I've felt that way in the past but eventually changed my mind...

Jason explains emphasis of 'Test-Driven Development':

The problem with Test-driven Development is that it's got the word "test" in the title. It's actually not as much about tetsing your code as it is about using tests to specify what code you should write in the first place.