- Specification Workshops
- Wishful Thinking
- Collaboration
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Collaboration
In the story of the Major International Airport Corp. we saw collaboration on multiple levels. Tony, the tester, joined the workshop together with Bill, the business expert, and Phyllis, the programmer. Later, while automating the examples they had identified in the workshop, Tony worked together with Alex.
Collaboration is another key ingredient to a successful ATDD approach. Consider what would happen if Tony worked out the examples by himself. He probably could have caught many problems within the software. These defects would have been bounced back and forth between Tony and the programmers—eventually getting both upset. In the end, when the product finally was delivered, the customer would have been unhappy about the misinterpreted corner conditions.
If this sounds familiar to you, consider a project that starts with a workshop. In this workshop most ambiguities would be settled between the programmers and the testers. The remaining questions would get answered before the team starts to work on the implementation. Since the examples express the requirements for the software, the team knows exactly when it has finished the implementation. There is some back and forth between testers and programmers. The programmers eventually find out about the value the automated examples bring them if they execute them before checking in their code to the version control system. In the end, the project delivers on time and with no problems.
To most teams new to acceptance test-driven development this may sound like a fairy tale. But there are many success stories of successful software delivery using an approach like ATDD in combination with other agile practices like refactoring, test-driven development (TDD), continuous integration, and the whole team approach. The combination of technical excellence on one hand and teamwork on the other hand seems to be a magic ingredient.
I also apply collaboration when automating tests. After all, test automation is software development and therefore, I want to apply all the practices and techniques that I also apply to production code. Most of the time I even take more care implementing support code for my tests than I take care for the production code. This means that I apply test-driven development, refactoring, and continuous integration to the support code as well.
Tony worked with Cucumber before he could get started with the support code. But he clearly did not have the expertise to finish the test automation code all on his own. When he noticed that he was stuck, he stopped work, and approached that team member that could help him and had the expertise with programming. Most teams new to ATDD confuse the collaboration aspect with the need for every tester to code. It makes the life of testers easier if they can work independently from programmers on tests and test automation, though. That’s why over time testers start to learn more and more tricks to automate their tests, but this is not a precondition. It is rather an outcome and a side effect in the long term.
Once I taught the approach to testers at a medical supplier. The testers were former nurses and had no technical education at all. Up to that point they tested the application manually. The programmers pushed forward for more test automation, but lacked the domain expertise the testers had. They agreed on an approach where the testers would get started with the examples, and the programmers would write most of the support code to get the examples automated.
Lack of programming knowledge does not mean that you cannot get started with the approach. Besides pen and paper, Tony didn’t need anything at all to get the examples down and use them as a communication device. In fact, most teams should start with such an approach, not automating the examples at all. The enhanced communication already improves the development process. You won’t get the full benefits of applying the whole approach, but the improved communication and collaboration will get you started. This comes in handy especially if you deal with a legacy code base that is not (yet) prepared to deal with automation code.