Hank Wallace turned me on to a post by Allison Shapira where she summarizes a key point from Rob Walker's writeup of the Blue Man Group - the "Why To" manual.

This "Actors' Journal" is not so much a how-to manual as a why-to manual; it's not about stage directions, but rather tells the story of the show step by step, from the point of view of the Blue Men. As a decoding and deconstruction of Blue Man's at-times baffling, even mystical behavior, it's a fascinating document, thick with references to everything from Being There to George Bernard Shaw to Robert Motherwell to the caves of Lascaux. Some explanations are straightforward ? "The Blue Men are not aliens" ? and others are more subtle, as when the trio's harmonic "three as one" relationship is described in terms of "blesh," a mix of blend and mesh borrowed from Theodore Sturgeon's science fiction novel More Than Human.

What would a "Why To" manual look like for a development team?

Miško Hevery has written a great summary of some basic coding rules for testability in his post Writing Testable Code.

I love this quote because every time I introduce unit testing to someone who has an existing code base you can see this in their eyes:

"I understand how to write tests for your code, but my code is different"

He goes on to list the rules most often broken by developers that make unit testing hard in his top ten list:

1. Mixing object graph construction with application logic
2. Ask for things, Don't look for things (aka Dependency Injection / Law of Demeter)
3. Doing work in constructor
4. Global State
5. Singletons (global state in sheep's clothing)
6. Static methods: (or living in a procedural world)
7. Favor composition over inheritance
8. Favor polymorphism over conditionals
9. Mixing Service Objects with Value Objects
10. Mixing of Concerns

A very nice woman (whose name I can't remember - sorry!) drew this for me during my SAO QA SIG talk.

Notice the signs the testers are carrying, these were points from my talk, so I know she was paying attention!

Brent has a great post on a technique for agile defect reporting.

Basically it comes down to 2 time horizons. The 10 minute and 30 minute horizons.

I was going to leave the following comment, but his comment system seems to be broken at the moment.

Thanks for the great approach for agile QA. Too many times it seems that QA groups get bogged down in the procedures, and can't see what they are trying to achieve (hint - it is not producing defect reports).

Scott Hanselman has started a podcast called HanselMinutes to talk tools and utilities. Episode #4 on Continuous Integration caught my attention because of 2 names mentioned during the discussion of the Ruby Watir library. Both Dustin Woodhouse and Travis Illig got mentioned because of tools they have written to integrate the Watir functionality at development or test time. Travis wrote RubyTestExecutor which hooks Ruby/Watir scripts up with NUnit. Dustin wrote WatirNUt which is a utility that creates a portable, testable NUnit binary wrapper around Watir test scripts and supporting files.

These two individuals and their tools are interesting to me because they both work on teams I manage and I'm excited to see my guys pushing the envelope.

Scott was also kind enough to mention me as one of the local XP experts (my 30 seconds of podcast fame).

Dustin, one of my co-workers, ran into a problem accessing
the "alt" attribute on image buttons using Watir and discovered a useful
trick:

Who knows if this will ever be useful to anyone else, but I've been
trying to work with imageButtons, which have alt tags. In HTML they render as
<input type="image".../> I wanted to
access the alt tag of the image. ie.contains_text wouldn't find it for me.
Only image objects in watir have any knowledge of alt tags.  And
unfortunately, watir recognizes imageButtons, not as images, but as
buttons.

there is almost no documentation that covers this, but I found that even
though these are buttons, you can use image methods to manipulate these
'buttons'. For example, you can get the object with:

• button = $ie.button(:alt, "This is the alt
  text...") *alt is only exposed for images, but works for
  imageButtons.

And you can manipulate the buttons with image
methods, such as:

Elisabeth Hendrickson has a great post about the practicalities of agile testing where she takes Brian Marick's breakdown of testing vectors and talks about what to actually do differently to achieve agility in testing.

Agile project teams generally reject the notion that they need an independent group to assess their work products or enforce their process. They value the information that testing provides and they value testing activities highly. Indeed, Extreme Programming (XP) teams value testing so much, they practice Test-Driven Development (TDD), writing and executing test code before writing the production code to pass the tests.  However, even though agile teams value testing, they don't always value testers. And they're particularly allergic to the auditing or policing aspects of heavyweight, formal QA.

So how can testers make themselves useful on a team that does not see much use in traditional, formal QA methodologies? Here's what I've been doing.

[via Elisabeth Hendrickson]