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.

I've conducted more interviews over the years than I care to remember. It's one of the things I do for my clients - help them interview people so they can make sure the candidates are thoroughly queried on their testing and agile knowledge.

I'm tired of...

...Interviewing people that haven't read a single book about testing...

...Interviewing people that don't have regular websites that they read to keep up to date on what's happening around matters relating to testing...

A while back, a colleague - Tim Smith - pointed me at Thomas Nagel's collection of philosophical essays in the book "Mortal Questions".

I was captivated by Nagel's seminal essay "What is it like to be a bat?"

Nagel’s essay discusses perception and poses a strong argument that there is no such thing as objectivity. I.e. we may distil a bat’s system of vision into the concept of Sonar but we can’t possibly know how the bat experiences it because we have only our perception of visible-light, our separate perception of audible sounds and the metaphor of a submarine's sonar to compare it to.

As some of you may recall, a couple of years ago I ran a workshop on Agile Performance testing.

You can find out more about this by searching for WOPR7.

The general theme, with the exception of one experience report, focused on post-hoc performance testing. A lot of work has been done over the last decade to advance functional test-driven development. When I say 'functional' I don't mean 'application level tests' (a.k.a. acceptance tests); I mean tests at the level of unit, acceptance and every level in between where these tests are concerned with functional behaviours (of the unit or the application respectively).