Exploration Through Example

Agile Alliance Functional Testing Tools Visioning Workshop
Call for Participation
Dates: October 11 - 12, 2007
Times: 8 AM - 5 PM
Location: Portland, Oregon
Venue: Kennedy School

Description
The primary purpose of this workshop is to discuss cutting-edge advancements in and envision possibilities for the future of automated functional testing tools.

This is a small, peer-driven, invitation-only conference in the tradition of LAWST, AWTA, and the like. The content comes from the participants, and we expect all participants to take an active role. We’re seeking participants who have interest and experience in creating and/or using automated functional testing tools/frameworks on Agile projects.

This workshop is sponsored by the Agile Alliance Functional Testing Tools Program. The mission of this program is to advance the state of the art of automated functional testing tools used by Agile teams to automate customer-facing tests.

There is no cost to participate. Participants will be responsible for their own travel expenses. (However, we do have limited grant money available to be used at the discretion of the organizers to subsidize travel expenses. If you would like to be considered for a travel grant, please include your request, including amount needed, in your Request for Invitation.)
(more…)

Class Fluid provides dynamically scoped (”fluid”) variables modeled after those of Common Lisp. It also gives you a convenient way to reversibly change the values of globals.

Fluid variables are useful when you want to pass information among related classes and methods without passing arguments all over the place, but you also want something a little more controlled than globals. They’re not useful all that often, but they come in handy once in a while.

The documentation (rdoc) gives more explanation and examples, such as the code that produces this amazing, never-before-seen feat of prettyprinting:

A tester is delivered supposedly-finished code that has nothing ready to test:

Half the functionality of a new feature has been introduced - the other half has not yet been completed. However the developers say this is working software because what was handed over works. But it’s no use to a beta customer site - can’t really show it to a user - can’t really test it as there is no flow. It’s a bit like saying a car ‘works’ when it has no back axle but please test away anyway because the front wheels are fine. Is there a definition of ‘working software’ anywhere?

I answer:

My definition: a feature is working if some person somewhere would be willing to pay more for the software with the feature than she would for the software without it.

Another way of putting it: at the end of every iteration, you should be able to sell the software for more money than you could at the beginning.

Sounds like your feature isn’t working.

As Chet Hendrickson pointed out in the thread, the trick is getting good at breaking Grand Ideas down into bite-sized chunks that can be implemented quickly but still do something useful. That can be hard to learn, but I’ve been impressed when I see it done well—impressed enough that I’ve come to the working assumption that it’s always possible. If you can’t see how to do it, that just means you don’t have enough experience and haven’t learned enough tricks of the trade.

Steve Gordon added:

If stories are split architecturally (horizontally), then the “working software” is quite like what you describe. If stories are sliced vertically (i.e., it does work end-to-end, but only for a few scenarios), then it is more useful for testing, feedback, and validating the architecture. Vertical slicing is what is recommended, but developers tend to think in components, so it is much easier for them to split stories into one for each component instead of figuring out which scenario (sometimes, a trivial one) they could actually do end-to-end through all the components within a single iteration.

In my experience, defining small stories is one of the toughest things for the product director to learn. Building an architecturally coherent system in small slices is one of the toughest things for programmers to learn.

As Jeff Patton has pointed out, there are dangers to small slices: it can be tricky to make everything hang together into a coherent, usable system. (See his span planning, for example.) Perhaps incorrectly, I emphasize getting good enough to be dangerous.

Everyday Scripting with Ruby comes with a library, anachronistically called s4t-utils. It’s mainly used behind the scenes to simplify working with scripts, but it also has a pile of utilities I use frequently.

By putting s4t-utils in a script’s third-party folder, a script writer can hand out her script as a single zip file and not force people to install different bits and pieces. (Rubygems handles collecting and installing multiple bits, but (1) using gems would require my scripters to make gems, and (2) they’d also have to run a local gem server for their local gems.)

However, if you’re making gems anyway (like I’m doing these days), s4t-utils might as well be another gem your gem depends on. So s4t-utils is now available from Rubyforge and thus via gem install --remote s4t-utils.

This version has a few small additions. It also has documentation of the general-purpose utilities.

For any number of purposes (exploratory testing, writing bug reports, getting examples for user’s manuals), I would like the following plugin to Quicksilver. It would be somewhat similar to the iGTD plugin.

• Invoke Quicksilver with its keystroke. Type ‘.’ to start writing a note. Write the note, strike one or a few keys to send it to the notetaker. The notetaker appends it to the open document.

• Invoke Quicksilver. With a few keystrokes, cause it to Grab a snapshot of the topmost window and append it to the document. (So the document handler has to be something that can handle pasted images. Note: if it matters, Pages will paste the image when you put an image on the clipboard and hit Paste. Word and OpenOffice give you the URL in that case. To get the image, you have to Paste Special. In either case, it would probably be best to use a different pasteboard than the one ⌘S uses.)

How hard could it be?

I’m going to start copying my replies to questions on agile-testing here.

I am interested in hearing how people that don’t think a Test Strategy should exist go about answering the following questions and when they do it. […]

• Number of testers required—including what skills they need (i.e. (Performance, Security, Domain Knowledge, Technical Knowledge) and where they will come from (current employee’s, contractors etc)

• Environments, especially for new projects. What is going to be needed, how much will it cost, when will it be required. (Some hardware can take 6-8 weeks to source)

• Data—what data will be used, where will it come from, privacy concerns

• External/Dependant requirements—for example will real users be involved in UAT/Usability Testing? When will they be involved? (If it is “general” public this needs time to organise, if they are in another country/offsite do you want someone to be there to monitor/oversee what they are doing). Is a usability lab going to be used? Does the product need to be benchmarked by an external company? When? etc.

• Software/Tools—if anything needs to be purchased this should be highlighted.

(more…)

This is bizarre.

The Guests Were Enjoying French Wine and Cheese on a Capitol Hill Patio. When a Gunman Burst In, the Would-Be Robbery Took an Unusual Turn.

Alistair Cockburn:

I’ve had to be part of and lead collaborative work sessions. People remark on the strong feeling of collaboration during those meetings, and the speed at which we get results. Other skilled facilitators manage the same. People ask us how we achieve these effects and whether it can be learned. With this article, I hope to show how we achieve these results, and that they can be learned. […]

In the end, three dominant categories of actions appeared. They are:

• Lift others
• Increase safety
• Make progress

Minor categories also showed up:

• Add energy
• Build personal relationships
• Create an identity

I am at best an amateur facilitator so this will be a handy checklist / self-retrospective-list for me. My biggest problem is dealing with what Sam Kaner calls “the groan zone“—the place where progress seems stalled and the group can either move through it or (more likely) fall back. At that moment, a whole bunch of people and ideas are in unstable equilibrium. What I’m not so good at is keeping the strongest personality in the group from tipping the equilibrium to a solution that meshes best with their personality. (Sometimes I’m that person.) Since, as Mencken said, “There is always an easy solution to every human problem—neat, plausible, and wrong,” it’s important to hold the balance.

That’s why I’m most comfortable with situations where we can agree to stop for now, go off and do an experiment that makes us know more. That’s not always possible—and, whenever it is, it requires convincing people to stay in the groan zone indefinitely.

Jason Gorman:

Contrary to - well - pretty much the entire software industry, I don’t believe that a software architect is someone who designs software. I believe that a software architect is someone who recognises a good software design when he sees one.

A Rails homage to the “I’m a Mac” commercials (via /\ndy)

The Wall Street Journal published an editorial containing this graph:

In what possible universe could you honestly fit that curve to that data? Who could, without shame, publish a curve that goes around the bulk of the data? One that goes through an obvious outlier? (Tukey’s brilliant and eccentric Exploratory Data Analysis counsels us to understand outliers before worrying about the “central tendency”. I wonder if the anonymous editorialist wondered what might be special about Norway? Perhaps a particular natural resource, drilled from under the ocean? If only there were a tool one could use to find information about that resource’s contribution to Norway’s GDP or any special tax rate applied to it!)

But, self-doubting liberal that I am, I can’t only conclude that unsigned Wall Street Journal editorials are written by people whose preferences and loyalties have made them—to use the precise academic terminology—bullshitters, people to whom the truth is completely irrelevant. I have to wonder to what degree I do the same thing, to what degree my own comfort and self-interest has led me to push back against the whole post-Agile thing, despite my respect for Jonathan Kohl and Jason Gorman.

Fortunately, I have morphing software to play with, so I can cut self-reflection short.

Hat tip to Economist’s View

For many web apps, it’s important to get the user’s workflow right. Consider a Rails app that uses some variant of acts as authenticated to handle user registration and login. Here’s one way of describing an example of normal registration:

John visits the home page.
John follows the “sign up” link.
(John is now on the signup page.)
John signs up as “john”, email “john@example.com”, password “sloop”.
(John is now on the welcome page.)
John waits for activation email…
John clicks on a URL ending in an activation code.
(John is now on the login page.)
John logs in as “john”, password “sloop”.
(John is now on the member page.)

Here’s another:

Which is better? If I were trying to design the workflow—get it so that it’s right for the users—I’d much rather use a picture (whether drawn in OmniGraffle, as this was, or on a napkin or whiteboard.) Why?

1. It’s easier to “zoom out” from a picture, to ignore the details. When I do that, I’m more likely to notice missing workflows or stupidities in the ones that I have.

2. As a designer, I’ll soon have to explain my thinking to others. It’s easier to explain a picture because it’s sitting right there in front of both of you, visible in two-dimensional space. It’s simple to refer to something you already mentioned: point at it. A wealth of context gets recalled by that simple gesture. If it’s not readily recalled, you can decorate the graphic with something that jogs the memory. Pictures make for a much more fluid way of communicating.

3. Our minds are in bodies; and bodies have minds of their own. We think kinesthetically and visually, not (just) by banging propositions together according to the rules of some kind of logic. The more ways you think about something, the fewer mistakes you’ll make.

But there’s one big disadvantage of pictures from the point of view of the test-driven (behavior-driven, example-driven) programmer: they’re not executable.

I’ve released an alpha version of an open-source library that converts such pictures into Ruby tests. Below the fold, I show how the workflow picture becomes a Rails integration test.

✂——✂——✂——✂——✂——✂——✂——✂——✂——✂——
(more…)