Acceptance tests are not a by-product of development

Long term maintenance cost is one of the biggest issues that teams face today when implementing agile acceptance testing. Tests that are just written and automated without any long term planning are guaranteed to cost you more than they are worth. But then again, a properly designed testing framework saves a lot of money, time and effort in the long run. It seems that the community is now going through the same learning cycle as we went through with unit tests, with people writing any crap code in unit tests at first, then learning that testing code maintenance hurts as much as it would hurt for normal code, and cleaning up their act. The ongoing research for my new book has helped me understand that, in the case of acceptance tests, the problem is much deeper. Continue reading

Effective exercises for teaching TDD

At the Goosgaggle event last month, David Harvey and I ran an open space session on teaching TDD through exercises effectively. My goal with this session was to learn what are the good exercises, what’s common for them, and why they are effective. There were roughly 20 people in the room so we had a good discussion and lots of great ideas. As with any other open space session, it’s hard to remember who suggested what first so I’m sorry about the rest of this post being more or less anonymous, but here are the ideas we discussed: Continue reading

How to implement UI testing without shooting yourself in the foot

I’m currently interviewing lots of teams that have implemented acceptance testing for my new book. A majority of those interviewed so far have at some point shot themselves in the foot with UI test automation. After speaking to several people who are about to do exactly that at the Agile Acceptance Testing Days in Belgium a few weeks ago, I’d like to present what I consider a very good practice for how to do UI test automation efficiently. Continue reading