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.
Self-portraits made using South Park Studio by Janina Köppel.
