ATDD by Example: Wish and Collaborate
This chapter is from the book
This chapter is from the book
This chapter is from the book
After this short iteration we will take a step back and reflect briefly. The functionality of the airport parking lot calculator was developed. Before the iteration started, the team discussed the requirements for the application that they should build. The format they used was a specification workshop [Adz09, Adz11]. The team identified different parking lots, and in that conversation they noted examples for different parking durations and the costs respectively.
After the examples were clear to the team, they started to work on the functionality. This particular team seems to work in parallel on coding and testing tasks. The tester wrote down the first example for the automation. After that he worked his way through the framework until he got stuck with the automation. You may recall that Tony started with a happy path example. When automating your examples, this is essential because it forces you to get the implementation correct right from the start before fiddling with too many details and corner conditions. The first example will provide insights about the necessary user interface for the end user. Starting from this basis, you can extend the examples in multiple directions. It does not really matter which happy path example you start with, if you apply responsive design techniques and object-oriented design. In this example there wasn’t much magic happening to the automation code, but there are some possible evolution points for this code. For one example all the dates seem to cluster around one particular date. In a future version of the automation code you may want to vary this, maybe leaving the calculation of particular durations to a helper class like a DurationFactory, which calculates randomized starting dates.
One important thing happened when Tony got up and walked over to a programmer, maybe the most important thing about successful test automation. A tester and a programmer collaborating in order to achieve the team goal of test automation provides great value when introducing the ATDD approach. Despite leaving Tony alone with the task to automate the tests, Alex offers him full support for the first test. Tony learned from Alex some of the underlying design principles and how to treat code to keep it readable and maintainable. Over time Tony got more and more familiar with test automation code. This enabled him to proceed with the automation code.
Let’s take a look at each of the three elements we saw here: specification workshops, wishful thinking, and collaboration.
Specification Workshops
In specification workshops teams discuss the stories for upcoming iterations. At first specification workshops appeared to me as a waterfall approach to requirements. Programmers and testers get together with some business representative to nail down requirements. But there are more benefits for agile teams to hold these workshops.
Getting everyone involved helps build a common language for the project. Eric Evans calls this language the ubiquitous language [Eva03]. When programmers, testers, and business people get their heads together to reach a common understanding about the project, they can sort out many misunderstandings before these blow up the whole project.
A workshop can help the whole team reach that shared understanding. There are some things you will have to keep in mind in order to make these workshops a success for everyone—regardless of whether they may be participating.
First of all, you should not waste the time of your business representatives. If you invite an expert user to your specification workshop, everyone in the room should respect the precious time of this person. A business representative could be a ProductOwner, a real user, or a subject matter expert for the application domain. If your team starts to discuss the latest technology at such a workshop, the business representative is probably going to reject your invitation the next time. At that point you will have lost crucial information for your application.
Pre-select some stories from your backlog. If you know which stories you will most likely implement in the near future, you can sort them out. If you end up with a list of stories that is probably too large to discuss in your allotted time for the workshop, then you have to cut it further.
For stories where the business flow seems obvious or straightforward to you, you can prepare data and bring those to the workshop. The business representative will value your engagement in the project and the easier stories. By preparing examples, you will also help keep the businessperson engaged and seeing the advantages of these workshops.
During the workshop it is crucial to ask clarifying questions. You can prepare yourself by going through the stories with your team and collecting open questions for the moment. Over time you may gain experience to come up more spontaneously with clarifying questions, but initially you may need full team feedback for the stories.
Finally, one element I consider mandatory for any meeting or workshop is visualization. Rather than leaving the discussion abstract, note down what you understand and ask for agreement based on your notes. You can do this publicly on a flipchart, or take notes on paper and share them around the table. For larger meetings I prefer flipcharts, while in a setting of three participants as in this first example, a piece of paper will suffice.
If your customer is located in a completely different country or timezone, you may want to try a different multimedia setting. With instant messaging and screen-sharing tools around, you can easily collaborate even if you are not in the same room with the whole team. However, you should set some preparation time aside to get these tools set up before the meeting.