For two days in the beginning of this week I have been on the Specification by Example workshop held by Gojko Adzic (@gojkoadzic). I can recommend the workshop for everybody interesting in Specification by Example.
We were ask to write down what we learned during the workshop so here is my notes and my takeaways from the workshop.
Day 1
Workshop 20 min
Rules
- Self organising teams
- The leaders of the workshop is the business users
Development can be in flow chart, lists, pseudo code or even SQL.
Develop a blackjack dealer from the requirements given. This lead to a lot of discussions about the requirements and even finding out that the requirements was wrong in some sense. This was done by discussing way the expectations was different between the groups.
It’s difficult to ask god questions, especially on the question, “Do you have any questions?”. One good question to ask is what is going to be tested. But how do we come up with good questions under time pressure?
We need to tighten the feedback loop, usually when we have developers that write the code and testers that test the written code later on, the feedback loop is too long. Also test have the problem that we have fewer testers then developer so that because the bottleneck of the process. Testing the code may spill over to the next iteration and when (not if) the find bugs, we are usually in the next iteration. Hence taking time from the next iteration with things that was marked as “done” in the previous one. So we have a hidden cost from that test starts to it is finished. This leads to process bankruptcy where we have to have a “clean-up sprint”, to clean up things that are not really finished.
We need to change the process so that the testers do not need to test everything at the end and tighten the feedback loop for the developers.
Feedback
- Implementation
- Understanding
- Scope
- Tests
- Assumptions
- Requirements
Get feedback early. Let testers make examples (green arrows) instead of testing the software (black arrows). Developers can then test it on its own. They usually automate the tests in some way when they are forced to run the test to see if the examples are fulfilled.
Death by Examples
There are one thing to lookout for when writing examples and that is Death by Examples.
Death by Examples is when the team spends hours on the details of the example. People adding lots of examples because they think that the domain is more complex then it necessarily is. Try to abstract things to make it easier to understand and this will also give you new concepts to talk about.
Facilitating a specification workshop
For a facilitator, think about the following:
- At least 2 groups
- Look for difference in the results
- Look for different level of information
- Compare the models with each other
- Discuss the scratch-out by asking “why did you scratch that out?”
- Define the scope
- Don’t skip the obvious, if it seems obvious, discuss it in 5 min, if everybody still think it’s obvious then it probably is.
- Listen to different opinions, there i no right or wrong here
- Make people talk – ask them leading questions
There are two different scopes when doing specification by example.
- One High Level that is good for planning
- One Low Level that is good for implementation
Workshop on specification quality
Tying to rate the quality of different specifications by the
- Level of information
- Structure
We should set points based on the following criterias
- Shared understanding
- Tests
- Documentation
A good technique to refining a specification with high detail is to try summarize the specification without losing precision. This reviles informations that is unnecessary to have in the example, still the information may be needed in the automation layer later but remove it from the examples.
Agile Testing Quadrant
Day 2
Recap from yesterday:
- Visualize the problem
- Make people to change them self by asking them to do experiments
- Waste snake, post-its with wastes
- Kick-starts the retrospective
- Measure the amount of questions that come up during development
- Measure the amount of boomerangs
- Better specification workshops
- Use flow based requirements as scope
- Work with the users to make user stories
- User story mapping
- Specification workshop, time-box the it in 5-15 min
- Don’t bother automating tests on simple tasks
Impact mapping
Deriving scope from goals (Hierarchical backlog technique)
- Way? (Goal)
- Who? (Users, stakeholders, actors)
- How? (Behavioural change => faster, better, cheaper)
- What? (Deliverables, Solutions)
Group stories on impact to help prioritising them
Refining a specification
- What are the examples?
- Output first
- Which inputs generates these outputs
- Play with the inputs (Boundaries)
- Descriptions / Title
Arrangement of tests in the living documentation
- Long term specifications based on features, use cases.
- In the current iteration by user story
- Tests that fails, but are to hard to fix at the moment
Mixed Q/A
Q: Geography distributed, how to do a specification workshop?
A: Prepare some user stories with Tree Amigos before meeting with the whole group. This will be like a mini specification workshoop. Tree Amigos is a small group of three with one person from business, one from test and one from development.
Q: Large flow-based requirements in word, how to convert them into specification by example?
A: Save the requirement as HTML and use Concordion or copy and past it into a tool like FitNesse. Add example for the different steps (as new pages) and automate it.
User group/Mailing list
Google mailing list, Specification by Example.
Books
Clean Language
Agile testing quadrant
Switch
Effect Mapping
ExploreIt – Elisabeth Hendrickson
Exploratory Software Testing – James Whittaker
How Google Test Software – James Whittaker
Videos
Michel Bolton
Collected some links here:
http://www.youtube.com/watch?v=XrYyQFtr_Mw
http://www.youtube.com/watch?v=VNfPwD9u9Bk
http://vimeo.com/41696681
Tools and Frameworks
Links
http://www.agileproductdesign.com/presentations/user_story_mapping/index.html
http://www.agileproductdesign.com/blog/the_new_backlog.html
http://gojko.net/2013/10/21/lets-break-the-agile-testing-quadrants/
Pingback: Specification By Example with Gojko Adzic | Aidium