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

Mon, 06 Jun 2005

Threat trees and others

Eric Jarvi writes a post on threat trees in response to my post on fine-grained guidance in exploratory testing. It reminded me of a short paper by Cem Kaner that I've always liked: Negotiating Testing Resources: a Collaborative Approach. Should be appealing to the big visible charts crowd. I recommend both links to your attention.

## Posted at 11:57 in category /testing [permalink] [top]

Form, content, and the structure of relationships

From an op-ed piece by Stanley Fish:

On the first day of my freshman writing class I give the students this assignment: You will be divided into groups and by the end of the semester each group will be expected to have created its own language, complete with a syntax, a lexicon, a text, rules for translating the text and strategies for teaching your language to fellow students. The language you create cannot be English or a slightly coded version of English, but it must be capable of indicating the distinctions - between tense, number, manner, mood, agency and the like - that English enables us to make.

You can imagine the reaction of students who think that "syntax" is something cigarette smokers pay, guess that "lexicon" is the name of a rebel tribe inhabiting a galaxy far away, and haven't the slightest idea of what words like "tense," "manner" and "mood" mean. They think I'm crazy. Yet 14 weeks later - and this happens every time - each group has produced a language of incredible sophistication and precision.

(Hat tip to rpg for the link.)

One of my pet obsessions these days is learning and teaching two guidelines of well-factored code:

Don't repeat yourself

Eliminating duplication seems key, but it's surprising how many programmers don't care about even the kind of duplication a program could find, much less subtler forms like boolean arguments.

And yet, we have people like (I believe) Ralph Johnson saying:

Once and Only Once is a profound concept, but difficult to apply. I've spent my entire professional life (25 years) learning how to apply it to programs.

And we have testimonials like Ron Jeffries':

I once saw Beck declare two patches of almost completely different code to be 'duplication', change them so that they WERE duplication, and then remove the newly inserted duplication to come up with something obviously better. [Ron: it would be tremendous if you could reconstruct the code.]

(Both quotes found here.)

Could we come up with words akin to "tense" and "mood" that make relationships of duplication clear to people who are middling language-writers but not language-understanders?

Intention-revealing names

As discussions of good method names show, we don't even have the right words to express this idea. "Intent" isn't quite right, and it's not exactly that good names say "what" vs. "how", and it's not really that names say "why" - but it is something. How to talk about that something?

Now, I'm certainly a fan of tacit understanding of what's inadequately captured by rules, so I don't believe that the two guidelines above can be completely captured by some syntax governing relationships, any more than I believe everything that natural language does is a matter of syntax. But if a knowledge of syntactic rules can help English writers, I expect a syntax of relationships (not the BNF of the language) could help Java writers.

I'm aware that I'm boldly heading to the 50's and structuralism, at least two intellectual fads ago. What of it?

## Posted at 08:51 in category /misc [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