Hi, Michael W:

>I've got a bit of a quandry. I'm an Agile/Xp enthusiast moving in to a
coaching role. One of the issues I keep running up against when working
with teams is how QA can handle the transition.

One important step is to stop thinking about testers as "QA" -- unless the A
stands for "assistance" or even "analysis", but not "assurance". We're
testers. Management (in one sense) and the whole team (in another) provides
the "assurance" bit, but since we don't have control over schedule, budget,
staffing, project scope, contractual obligations, customer relations, etc.,
etc., we can't assure anything. We should be here to help--not to slow the
project down, but to aid in the discovery of things that will threaten
value.

I shiver when I hear the words "up-front" -- which are forever linked to
"big design" in my head. I also shiver when I hear "acceptance criteria"
mentioned, since the question of /whose/ acceptance is often begged, and
acceptance /for what/ is also unclear. "Acceptance criteria" for me has a
strong whiff of "negotiated contracts" and "following a plan", where the
essence of agile to me has always been "customer collaboration" and
"responding to change".

So one big role for testers--maybe the biggest, in my view--is to promote
the discovery of things that have not been anticipated by the contract and
the plan, and that may require change and collaboration to sort out. That's
an ongoing process. Discovery can't be scheduled. Investigation can, to
some degree, but it doesn't stop just because the end of the iteration has
been reached. It doesn't stop until the product is shipped.

One of the biggest issues I see with transitioning to agile is that the
development teams have historically seen testing as task set ("write down
this and this and this and this; confirm this and this and this and this"),
and not a mind set ("/is there a problem here?/"). The testers themselves
are often locked on to this notion more than anyone. Most of the /tasks/
can be done by practically anyone on the team. Confirmation is relatively
straightforward. If there aren't enough testers to do X, Y, and Z, someone
else will have to do them, or you'll have to get more people to do them, or
you'll have to wait. The latter two are probably less acceptable than the
first, so the mindset that has to get fixed here is that only the testers do
this kind of testing. (That was a factor how XP got started, if I
understand the history correctly; Programmers and Customers would take more,
much more, responsibility for this kind of confirmatory testing, more easily
done by machines that are directed by skilled programmers who get the
benefit of immediate feedback into the bargain.)

Investigation is different. Investigation involves probing the product to
reveal /new/ information; asking and answering questions about known
unknowns, and moving them into the space of the known; and recognizing
hitherto unknown unknowns, and moving them into the space of known unknowns.
Consider it as the antidote to "Mission Accomplished"-style thinking.

Note, by the way, that not all traditional testers are going to be able to
do this kind of work, since traditional testing and early thinking about
agile testing bludgeoned many testers into believing that confirmation was
all there was to it.

One last thing: when we call it "manual testing", note that the only thing
manual about it is the input mechanism. James Bach uses the term "sapient
testing" (See http://www.satisfice.com/blog/archives/99; the discussion that
follows in the comments is important too.) I don't like the term much but I
can't find a better word for it. Sapient testing is what humans think and
do, and is fundamentally and by definition not automatable. Sapient
processes can be aided by tools, but not replaced by them.

And, uh, one MORE last thing: have a look at the recent discussions on
"test-first development" (different from the TDD sense) in the
software-testing mailing list for some insight into the "acceptance
criteria" problem.

---Michael B.

________________________________

From: agile-testing@yahoogroups.com [mailto:agile-testing@yahoogroups.com]
On Behalf Of Wilson, Michael
Sent: February 4, 2008 11:55 AM
To: agile-testing@yahoogroups.com
Subject: [agile-testing] Transitioning into Agile: QA's Role




There's an abundance of literature and (dare I say it) Agile doctrine on
their role once a team is running all nice and agilifically. But repeatedly
during discussions hallway and formal QA people are left with this feeling
that we're patting them on the head and asking them to do the double work of
their manual testing while adding up-front acceptance criteria and test
formulation to their role.

QA already gets pulled too thin and watching them sigh in justifiable
resignation that their workload's going to increase is a bit disheartening.

I'd be interested in thoughts on easing the pain here.


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
This message is for the named person's use only. This communication is for
informational purposes only and has been obtained from sources believed to
be reliable, but it is not necessarily complete and its accuracy cannot be
guaranteed. It is not intended as an offer or solicitation for the purchase
or sale of any financial instrument or as an official confirmation of any
transaction. Moreover, this material should not be construed to contain any
recommendation regarding, or opinion concerning, any security. It may
contain confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission. If
you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify the
sender. You must not, directly or indirectly, use, disclose, distribute,
print, or copy any part of this message if you are not the intended
recipient. Any views expressed in this message are those of the individual
sender, except where the message states otherwise and the sender is
authorized to state them to be the views of any such entity.

Securities products and services provided to Canadian investors are offered
by ITG Canada Corp. (member CIPF and IDA), an affiliate of Investment
Technology Group, Inc.

ITG Inc. and/or its affiliates reserves the right to monitor and archive
all electronic communications through its network.

ITG Inc. Member NASD, SIPC
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-