Anti-spamming software is an integral part of many websites, often taking the form of “type in the distorted text you see”. The assumption is that this is – hopefully – too difficult for a machine to do quickly and trivially, but easy for humans with our better pattern-understanding skills.

reCAPTCHA is an example of this which takes this a step further: the second word is used to confirm I am indeed human and not spamming, while the first word is text from a failed attempt to digitize historic documents: i.e., reCAPTCHA provides a (free!) way to get humans to help digitize old text from before the computer era. This is a great idea, but does throw up some interesting examples in practice:

It’s obviously rather harsh to expect someone to be able to enter (i) a mathematical forumla with superscript and subscripts and (ii) Greek text, particularly as the text box only accepts plain English with no formatting. More worryingly, I got thinking about whether other even more inappropriate (i.e., offensive) data might wing its way to the user. I followed this up, and got the following response:

“The facility does have filters in place to prevent offensive words coming up…  some of the words in these texts are difficult for computers to process, we are using the results of your efforts to help decipher them.”

Which makes me wonder: if the texts are difficult to process, how can we truly be confident in any filters? And how should a tester go about raising a concern like this: is it a real defect? Or just a worry…?

I’d like to thank one of our senior developers for inspiring this post. Dave Vines recently sent out an excellent, thought provoking email on how we should be moving towards a tester driven development model. I’ve slightly reworded his email:
“One thought that I’ve recently had was that perhaps we need “Tester Driven Development” rather than “Test Driven Development”. Let me try to explain.

We are currently very much a “Developer Driven Development” organization:
We gather new requirements and (typically) farm them out to the development community to investigate
Once a work item is identified, it is typically a developer that

• Writes the Design document
• Calls the meeting to develop the use cases
• Identifies the interesting scenarios
• Gathers the development resource to write the code
• Decides which iteration in which the code will be written
• Hopes that test will have the resource to test all the use cases and “interesting edge cases” that have been identified and for which code has been written (or not written)

In effect the developer owns the work item

In a “Tester Driven Development” organisation I would see us:
Gathering new requirements and (typically) farm them out to the test community to investigate
Once a work item is identified, it is typically a tester that:

• Writes the design document
• Calls the meeting to develop the use cases
• Identifies the interesting scenarios
• Gathers the test resource to test those scenarios and use cases
• Decides which iteration in which the code will be tested
• Indicates to development what use cases and code will be needed and when

In effect the tester owns the work item

This would be a massive culture shift for a department, but one that makes it clear that the desired deliverable is actually requirements that have been tested, not requirements that have been coded and may have been tested if test had enough resource. “

(more…)