Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick

191.8

⇒

167.2

⇒

186.2

183.6

184.0

183.2

184.6

Fri, 23 Jan 2004

Community

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 misleading?

I've not studied the social science literature on community, but I should. Ben Hyde has read more than I have. I recommend two postings:

• Communities
• Communities of limited liability

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 [permalink] [top]

GUI testing prejudices

Someone on the agile testing 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 it.

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.

• Javascript is a pain for testing. I'd use the above freeware tools 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 XML-RPC route.

• Probably before that, I'd do some serious hunting for writeups by those people who hang out on TestFirstUserInterfaces@yahoogroups.com.

For both types:

• It's easy to get sloppy or mindlessly repetitive in manual testing. Pairing is a way of keeping attention and discipline up. I'd try to make sure to apply it.

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 progresses.

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 Bret Pettichord.

## Posted at 07:50 in category /testing [permalink] [top]