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


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:

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]

About Brian Marick
I consult mainly on Agile software development, with a special focus on how testing fits in.

Contact me here: marick@exampler.com.




Agile Testing Directions
Tests and examples
Technology-facing programmer support
Business-facing team support
Business-facing product critiques
Technology-facing product critiques
Testers on agile projects

Permalink to this list


Working your way out of the automated GUI testing tarpit
  1. Three ways of writing the same test
  2. A test should deduce its setup path
  3. Convert the suite one failure at a time
  4. You should be able to get to any page in one step
  5. Extract fast tests about single pages
  6. Link checking without clicking on links
  7. Workflow tests remain GUI tests
Permalink to this list


Design-Driven Test-Driven Design
Creating a test
Making it (barely) run
Views and presenters appear
Hooking up the real GUI


Popular Articles
A roadmap for testing on an agile project: When consulting on testing in Agile projects, I like to call this plan "what I'm biased toward."

Tacit knowledge: Experts often have no theory of their work. They simply perform skillfully.

Process and personality: Every article on methodology implicitly begins "Let's talk about me."


Related Weblogs

Wayne Allen
James Bach
Laurent Bossavit
William Caputo
Mike Clark
Rachel Davies
Esther Derby
Michael Feathers
Developer Testing
Chad Fowler
Martin Fowler
Alan Francis
Elisabeth Hendrickson
Grig Gheorghiu
Andy Hunt
Ben Hyde
Ron Jeffries
Jonathan Kohl
Dave Liebreich
Jeff Patton
Bret Pettichord
Hiring Johanna Rothman
Managing Johanna Rothman
Kevin Rutherford
Christian Sepulveda
James Shore
Jeff Sutherland
Pragmatic Dave Thomas
Glenn Vanderburg
Greg Vaughn
Eugene Wallingford
Jim Weirich


Where to Find Me

Software Practice Advancement


All of 2006
All of 2005
All of 2004
All of 2003



Agile Alliance Logo