One of the key things missing from a lot of places where people try to implement agile acceptance testing is working collaboratively on examples. Although this sounds as a minor issue, in fact it is one of the core practices. If it is missing, there is no way to get the full benefits of acceptance testing and teams often get disillusioned with the whole idea. Ian Cooper recently wrote about his experiences before and after introducing the workshop, concluding that “this seems to have removed a lot of the pain”.
##Collaborative requirements and specifications
Specifications written by a single person do not harness the knowledge and experience of all people on the team, in particular technical people are often left out of the loop. Collaborative specifications are often better in the sense that they are more complete, easier to implement and more consistent with the technical infrastructure.
The best way to get collaborative specifications is to organise a workshop at the start of each iteration. The goal of the workshop is to discuss examples of stories that are planned for the iteration. The discussion leads to investigating edge cases, identifying functional gaps and inconsistencies before the development starts. A tangible output of the workshop is a set of realistic examples demonstrating important cases for the user stories planned for the iteration, which can be easily converted to acceptance tests.
An even more important output of the workshop is coordinating the thoughts and the understanding of the domain in the heads of business people, developers and testers. The workshop also facilitates a transfer of domain knowledge to developers and testers, allowing them to learn about the domain first hand and avoid the effects of the telephone game. This shared understanding is, for me, even more important than the physical acceptance tests. Unfortunately, this output is not tangible, which is why the workshop often gets skipped and replaced by just a single person writing tests.
##A new name
Regular readers of my blog or people who have seen my acceptance testing presentations will probably recognise these ideas under several names, because until today I did not really have a good name for the concept.
I initially called this “the acceptance testing threesome”, suggesting that business people, developers and testers need to work together. This was labeled as offensive by some people so I changed it to acceptance testing meeting, but having the word “testing” in the name caused a lot of confusion as testers thought that they should take charge and business people often did not understand why they need to participate. I later changed this to “example-writing workshop” to emphasise that the workshop should be focused on writing and discussing examples. This was better in the sense that “testing” was no longer an issue.
Participation of the business, both in terms of domain experts and stakeholders, is crucial to get these workshops right. Domain experts will know how the system should work, but they rarely control the scope. Someone has to be able to say yes or no to edge cases, ideas and identified functional gaps. Workshops can also provide quite a good project progress visibility to such stakeholders, but “example-writing workshop” is not something that they feel obliged to participate in.
After one persuasion session with a project stakeholder this week, I think that I finally have a good name that is self-explanatory enough to ensure that stakeholders want to be there. So I propose yet another new name for the concept. Specification workshop makes it was clear that the business needs to be present there, both in terms of defining the contents of the specification and controlling what goes in or out.
