Fri, 23 Jan 2004
As someone who wants us all to join together under the banner of
Agility, I'm a big fan of the rhetoric of community. And I do feel a
sense of community, a sense of belonging. Nevertheless, I'm nervous
about Community as a metaphor. What does it suggest that's
I've not studied the social science literature on community, but I
Ben Hyde has read more than I have. I recommend two
I'm particularly taken by the first posting's description of rituals
and traditions. Something clicked when I read that. My goal is to
merge some part of the testing community into the agile
community. In the process, the former will be transformed more than
the latter. Some of the rocky experiences I've been having can
perhaps be explained by my inattention to rituals and traditions.
## Posted at 17:27 in category /misc
GUI testing prejudices
Someone on the
mailing list asked about testing GUIs in agile projects. Here's
my reply, somewhat edited.
My prejudices today, January 22 2004, go like the following. I hope
that in a year they're different. It would be sad if neither I nor
the field changed.
Make sure you have good automated tests for the domain model / guts
before worrying about automating the GUI. This automation is done by
programmers, testers, and the business expert, each contributing
according to skill and need.
You will always do
exploratory manual testing, so get good
at it. I especially like to use exploratory testing to seek out
omissions in the original story, what Kevin Lawrence calls "testing
around the edges of a story". But exploratory testing should also
concentrate on what the stories don't. If stories are about features,
make exploration be about user tasks. If the stories assume expert
users, do exploratory testing that favors novices.
I like having the whole team do
exploratory testing as part of an end-of-iteration ritual. You may
need other exploratory testing besides; let experience drive you to
For testing web GUIs:
In some styles of implementation, the GUI is a transform
from objects (the model) to text (HTML). Sounds like a job for unit
testing. I'd rely heavily on that. The GUI implementor really ought to
poke manually at the GUI after changing it; I'd see if there are ways
to have her do it exceptionally skillfully. If poking is too hard (too
many screens to navigate through), I'd make it easy.
I'd use one of the freeware drive-IE-via-COM tools (like
WTR) to make some
smoke tests, but this would be lowish priority.
to find some way to let me unit test it. But, again, I'd think
carefully about when manual testing suffices.
Configuration testing (IE vs. Mozilla vs. Safari vs. Netscape 4.71
with cookies turned off vs. ...): Oh Lordy. I don't know enough about it, so I
would seek the advice of someone who does.
For testing the other type of GUIs:
Exploratory manual testing and programmer manual testing is my first
defense. Actually, my first defense is making the GUI thin: get that
business logic where it belongs!
I've heard good things from people who drive the GUI from
"underneath", in the sense that they send instructions to the app (via
something like XML-RPC), then the testability code in the app inserts
events in whatever event queue the GUI framework provides, then the app
does something, then state (GUI and perhaps model) is queried via the
Probably before that, I'd do some serious hunting for writeups by
those people who hang out on
For both types:
I refer to these as "prejudices" to reinforce to myself that
they're just a starting point - in two ways. First, they're a
starting point for my thinking as I approach a new project. Second,
whatever approach a project starts with must change as the project
The word "prejudices" also reminds me that I haven't done enough
thinking, nor enough practice.
I think I picked up this explicit use of the word from
## Posted at 07:50 in category /testing