Agile Testing UK meetup

While in England for DDD Exchange, I caught the opportunity to participate in a meetup of the UK Agile Testing community. Gojko Adzic led a very interesting workshop about how to write acceptance tests.

Neil McLaughlin, who happened to be in my team in the hands-on simulation wrote a nice report on the evening, and then Gojko himself posted about what he showed us. I'll try add something, from the participant perspective.

The developer mindset

Given we had quite a few people in the room, around 60, it was really interesting to note all different behaviors, but there were also some striking similarities. Most of the discussion we had were focused on

• Formal correctness of the test
• Splitting tests to be testing one concern at that time
• avoiding duplication in test fixture setup

When discussing the outcome, Gojko pointed out that the main concern for acceptance tests was readability, instead. Readability is a subjective evaluation criteria, and might lead to a not-so-precise definition about how to make it right. But that's the only way to write a useful acceptance test. But the developer's mindset really had a strong influence on us, it was really hard to give up.

Constrained by the tools

Despite Skills Matter (that was hosting the evening) doing a fantastic job in providing an impressive amount of whiteboards for all the team, some of the discussions were constrained by the amount of space available on the whiteboard, so we ended up pruning some concerns, thinking they were of little value to the discussion. It turned out we were wrong.

But, as I said, we had an amount of writable space that was a lot larger than what I normally found in a typical workplace... and still this was constraining us. Buying one more whiteboard is cheap, making wrong assumptions because of writable space constraints is a lot more costly.

We're problem solvers, after all

During the exercise, Gojko was wandering around from one team to another one, playing the role of the Domain Expert. However, most of the teams seemed more interested in his Teacher role and asked some questions about how to solve the exercise, but barely none about ambiguities in the domain. We preferred to use assumptions instead.

Even if I knew the trick, it worked on me as well. But it's scary to note that even when writing acceptance tests, which are a lot more translation than design, our built-in problem solving brain leads us so easily on the road of guessing instead of asking.