On Monday, March 22, 2004, at 11:13:33 AM, Brian Marick wrote:

> There are two separate issues. One is to convince self-identified
> Programmers that they want 100% automated tests. That's not the topic
> of my note.

Yes, understood and agreed.

> The other is to convince some subset of self-identified Testers to let
> go of ownership over the test automation decision. That's hard, because
> the burden of automation has traditionally fallen on them, and it's
> historically quite often led to less-effective bug-finding.

I guess that's "an" other, though I'm not convinced it is "the" other. I
want the /burden/ of automation to fall on the whole team -- and recognize
that it quite often falls more in the developers -- and I want the burden
of deciding what the tests must be to be shared, but expect that with good
testers, they'll carry most of that burden, if burden it be.

> My solution is to be very explicit that they get to decide on how to be
> effective at bug finding, and that no one else should tell them that
> necessarily involves automation. In return, *they* do not get to judge
> what amount of automation best serves programmers who are looking to
> tests for support in their coding work.

I like where this is going. "You folks decide what has to be tested. You
other folks need to build an impervious network of automated customer- and
tester-defined tests, to support your refactoring and design evolution."

I sense that I could work that way ...

> What I want to do is shift the conversation away from "tests" as some
> single unified thing that has exactly one purpose.

I see the truth of it! -- Paul Muad'Dib

Ron Jeffries
www.XProgramming.com
The main reason that testing at the end of a development cycle finds
problems is not that problems were put in near the end, it is that
testing was put off until then.