Mar
24

SPA 2008 (2)

Awesome Acceptance Testing

I went to this session expecting a good delivery by Dan North and Joe Walnes about a subject I knew already. It was entertaining, as expected, but I also learned some new things. The session was about more than ‘just’ automated acceptance testing.

Properly done, acceptance testing runs throughout the project, from initial ideas about the product to final delivery. This changes the way of working of customers, analysts, testers and developers. Much of the session was about the vocabulary these roles use (the ubiquitous language), the way they interact and how acceptance testing (tools) supports the whole process.

Alot revolves about the simple acceptance testing structure of

Given <some context>,
When <something is done>
Then <this should happen>

A lot of tools go far (very far in the case of some Ruby DSL), but you can do it very simply in whatever language you have at hand. The only requirement is that you clearly express the intent.

Last year, I paired on some acceptance test code. We naturally arrived at the structure above, by improving the expression of the intent. At some point, there was duplication in the tests. So, we refactored it out, as you do on an agile team. But then, the tests lost a lot of their expressiveness. We put the duplication back. This was in java, a language I find difficult to read, but the testers and analysts easily managed to skip over the syntactic warts and read the tests as almost natural text specifications.

At my current project we have come to a similar convention for bug reports:

Given <some context>,
When <something is done>
Then <this happens>
While <we expected this>

Matt Wynne summed the session up clearly as:

  • Have a shared understanding of done
  • There is no Golden Hammer
  • Be aware of the five aspects of test automation: Automation, Vocabulary, Syntax, Intent, Harness
  • Start simple, benefit today

Automatic for the people – process implications of of automated testing

Another testing session, this time by Keith Braithwaite. Keith started with an obvious platitude: “IT is a people business. People build stuff for People so that other People can do stuff”. Yawn. That’s obvious! Or is it? More about that later…

Keith started out by asking who of us has their users write the acceptance tests? I don’t: most of my users are only starting to learn how to write 😉

Keith then showed how he let users specify what they wanted by giving examples. These examples where then used as specification and automated acceptance tests with relatively little effort. There was little time left, because on one project most of the testing budget had already been blown. The projects were successful. No issues have been reported.

Why do these examples work so well? Why is it easier for experts to give us examples than rules? As, Keith said, “the world is messy” and experts are unconsciously expert: they no longer use the rules explicitly, but can use them effectively when faced with a situation. I saw this in action last year with an HR system, where the rules had been shaped and bent in the course of tens of years of industrial strife and negotiation. There were a myriad rules, each with their exceptions. But the HR people could give an answer when faced with a specific situation.

This all ties in well with the awesome acceptance testing session, the acceptance tests are the examples.

Getting to No

Another entertaining and informative session hosted by John Nolan. Unfortunately, Paul Dyson wasn’t there to add his usual spice to the show.

The session looked into why we find it so hard to say no. I’ve refused a few projects and stopped some. I’ve never regretted saying NO to them. I do regret lots of cases where I said YES. So, why don’t I say NO more often?

We worked in pairs during the whole session. I paired with James Robertson. We each told a story where someone should have said NO or STOP, but everybody kept going. We then looked at why saying no was difficult in the given situations, the pressures to say Yes and the consequences of saying No. Finally, we gathered ways to say No effectively.

I liked the alternation between pairing and plenary work, generalizing from specific stories. John Nolan kept us going with his funny, contrarian position (“Beware the evils of win-win!”).

James Robertson and Immo Huneke have more notes about the session.

These three excellent sessions were a strong finish for the conference.

Leaving

Portia, Vera and I left before the closing plenary to be in plenty of time to catch our train. On the way back, we still had enough energy to generate more ideas for XP Days Benelux and the “Real Options” session at the next XP Days France. Hope to see you there!

A big shout out to Andy Moorley for another flawless organisation.

Thank you to the old and new acquaintances I talked to during the conference, especially Vera and Portia. You were the highlights of the conference.

VeraPascalPortiaMark

Self-portraits made using South Park Studio by Janina Köppel.

Mar
20

SPA 2008 (1)

Back from SPA

I’ve just returned from 4 days of intensive, relaxing, active and interactive sessions and discussions at the annual SPA conference. The fun started early for me, because I traveled to the conference in the company of Portia, the Wicked Witch of the West and Vera, the Good Witch of the North.

Beware of the dwarves!

Snow WhiteIn “Mirror, Mirror on the wall“, Portia Tung and Chris Coopers-Bland told us the story of Snow White and the Seven Dwarves and then held up a mirror to the participants. Identifying people we know as characters from the fairytale told us a lot about ourselves and how we see people. We all know people who are like Snow White or Grumpy or even the occasional Evil Queen. Or are they really? What is it in our behaviour and way of looking at the world that makes them appear so? At the end of the exercise we all found ways to act differently with these people.

In a second exercise we had to make up a team for a task with the characters from the “Snow White and the 7 dwarves” kanban deck. This allowed us to become more aware of team composition, by combining people with characteristics that reinforce each other. The 7 dwarves characters acted like the Belbin Team Roles, but were a lot more fun. This was the second episode in the “Agile Fairytales” series, after the “Yellow Brick Road“. Watch out for more agile fairytales at a conference near you.

More about the dwarves (and other sessions) on Portia’s blog.

Real life options

I helped out with Chris Matts‘ and Portia Tung‘s session on Real Options. Real options are a deceptively simple idea. But it’s very difficult to explain, as we found out during the session. Real Options underlie both Lean and Agile. They allow us to deal with uncertainty more effectively.

The session had a lot of energy and chaos in a very small, packed conference room. We tried to do too much in the session, which meant that the message probably wasn’t as clear as possible. Real Options generated some more discussion at the conference. I’m still mulling over the implications of Real Options and how best to explain them. On the way back from the conference, Portia, Vera and I developed different ways to explain (and experience) real options. More about Real Options in the future! Meanwhile, check out this InfoQ article about Real Options.

The creative process and teamwork techniques

One of the six thinking hatsIn the evening, Portia, Vera, Charles Weir and I discussed the Mirror Mirror session. The session mentioned some teamwork tools and Charles wanted to know more. So, we developed a session using the “Creative Process“, that would give Charles the information he wanted. This all went very quickly and smoothly, a great example of creative, collaborative work.

The next day, we presented this session as a BoF (Birds of a Feather). Again, we experienced a group of people doing creative, collaborative work and coming up with results.

Each of us listed teamwork techniques that we had used successfully. We selected the four most popular ones and created “Sales pitches” for each of them. Finally, someone presented the tools to the whole group. As you can see, selling the “6 Thinking Hats” technique doesn’t have to be boring.

The results of the BoF are available on the SPA wiki.

Team work techniques 2Team work techniques 1

More later…