We had been to this one-day conference a couple of years ago, and were keen to go again. Especially as Chris Matts was on the speaker list. It was his work as a BA working with Dan North that really brought BDD to prominence. His session was an innovative experiment, see further on for more details.
The venue was away from the normal SkillsMatter location, and instead the talks were held in the crypt of the church on the edge of Clerkenwell Green, a short walk from Farringdon station. Registration was 8.30 – 9.00, but by 8.45 the crypt was already full. Many had taken full advantage of the fresh coffee and boxes of pastries thoughtfully provided by the organisers. We settled down for the first talk of the day: Gojko Adzic and Christian Hassa.
Gojko is the organizer behind the BDD exchange, and he spoke first to explain the format. They had found the year before, that a presentation as a conversation between two speakers on stage worked very well. So they had based all the talks this year on that presentation model. Overall this presentation model worked well, but occasionally there were gaps where one speaker would look expectantly at their co-presenter.
How I learned to stop worrying and love Flexible Scope
Gojko and Christian addressed Flexible Scope and the perils of “Water ScrumFall” and “BanKan”. The perennial compromise where cost and scope can be adjusted, but ultimately there is only so much time. They advocated fierce prioritisation from the beginning, not just when the project is “in crisis”. They even suggested that teams start charging for flexibility, so that if that is what their customers value, then they should understand it comes at a cost.
They highlighted 3 dimensions that cause linear plans to fail (quoting from a 19th century Civil Engineer):
- Time
- Locale
- Human.
I.e. things change; contexts can be specific; humans will do what they want, not what the application expects.
They also highlighted 3 principles of adaptive planning:
- Variation
- Survivability
- Selection.
I.e. Don’t second guess the search space; many plans will fail only some will survive; get good feedback on your ideas.
User stories have to be survivable, and provide good measurable feedback. Remember that there can be more than one solution in the search space, they may all be usable, but there may be a high cost to ‘push’ over the topology from one solution to another.
They invited the audience to create a ‘GPS for their business’. A roadmap that allowed you to change direction, rather than one that keeps you in a darkened tunnel, ignoring your surroundings, determined on the one true course to delivery. Instead the envisaged working to a GPS style roadmap that allowed re-planning at every turn, and User Stories that provided and absorbed business level feedback.
When people are asking for control. They don’t want control, they want visibility.
Elisabeth Hendrickson
Thinking of stories as survivable experiments lets the team know the impact that the features they are creating will have in terms of business value. Mapping these impacts ensure that the development team understand the value they are creating.
One consideration is that treating stories as survivable experiments looking for survivability, variation and selection introduces a number of evolutionary principles to the toolkit, without openly advocating a completely non-deterministic process like a Genetic Algorithm. The expectation seems to be that we are exploring an evolutionary or ecological search space, and that we should discover solutions as though there are multiple stable states available within that search space. This may, or may not, reflect the actual business domain to be addressed.
After coffee and catching up with other attendees Matt Wynne and Seb Rose gave us:
Whose Truth is it Anyway?
This started as a role play between a website designer/developer and a Used Car business owner, trying to get on the web. This neatly highlighted the knowledge gap between technical and business domain experts. While diamante gearsticks were highlighted on the website, VAT was not being charged on transactions. Even using a tool like Cucumber with Gherkin syntax was not enough to avoid these pitfalls.
The creation of a ubiquitous domain language can certainly help to provide a common language between the two domains, as long as you stay in the problem domain and do not venture into the solution domain. That is, descriptions in stories should be about the problems to be solved, not the type of solutions you might use. Any evidence of web elements like clicking, filling, etc. in the story definitions is a smell that you are drifting into the solution space and away from the problem domain.
The level of detail in stories can also indicate the level of trust that domain users have in the team’s domain knowledge. Although it may also belie micromanagement and/or controlling techniques.
This setup then allowed the speakers to describe not just the normal testing triangle, but also the testing iceberg.
End-to-end system tests are still a thin slice at the top of the iceberg (nee pyramid), but there is now also a waterline indicating the boundary between business readable, and technical, tests. The majority of ‘end-to-end system tests'(ITs) are business readable, but you can also see that the further down the iceberg you descend the more the tests are below the waterline and technical. The ‘Tests that verify integrated components or subsystems'(ATs) are roughly half and half either side of the waterline, whereas the ‘Tests that verify components in isolation'(UTs) are 90% below the waterline as they are mainly technical.
N.B. I’ve roughly mapped these types of testing to our preferred terms where:
- IT : Integration Test;
- AT : Acceptance Test;
- UT : Unit Test.
What do Testers Do?
Tony Bruce (organiser of the London Tester Gatherings) and Adrian. Unfortunately this conversation was a little one sided as Adrian was ill. The audience took the role of Adrian as we whistled through a mind map of what it is to be a tester. The audience interaction often filling in the blanks before we whizzed across the mindmap to the next section.
This took us to lunch, a mountain of pasta boxes, and the opportunity to chew over the mornings talks. After lunch were another 3 talks, pizza and beer, and a park bench panel. The three talks were quite different.
David and Bri gave us:
Two sides of the story
I particularly liked the use of a quote from Lincoln’s Gettysburg address used to illustrate the difference between the throwaway User Story (card) we create, and the long lived application feature that results from that story. These two were highlighting not just the use of stories, but also contrasting good and other practice in creating them.
Chris Matts ran an interactive trans-Atlantic Skype session with his group of BA experts taking questions on BDD from the floor, and the Sparkle team ran us through the journey of their development process via peeling back the layers of the feedback onion.
To see podcasts of the talks go to Agile Testing and BDD Exchange 2013 and scroll down. There is a link against each talk.