Over the course of my career I’ve had the pleasure of working with some great agile teams. I’ve also had some bitter disappointments working with great developers, testers and BAs who just don’t get it… Many of the teams that get it didn’t actually use natural language to create executable acceptance tests, however they did […]
I’m about to write a few articles covering some advanced acceptance testing techniques. I don’t plan to get into the nitty gritty technical details and instead want to discuss the why’s… For some great material around acceptance testing I highly recommend looking at the Concordion techniques page and can’t speak highly enough of Gojko Adzic […]
I’ve written in the past about Using English to write Acceptance Tests and the tool I choose/advocate is without doubt Concordion. Customers love seeing their stories come alive, but I’ve found developers can sometimes struggle to differentiate these from JUnit tests, particularly since JUnit is used to provide the execution mechanism. I’ve also found that […]
Another emergn coach asked me the other day how I distinguished between an acceptance test and regression tests. For me there is a very simple rule… If I write the test before I write any code, it’s an acceptance test. If I write the test after I’ve written the code, it’s a regression test. If […]
Following on from my previous article, I thought I would share some top tips for creating automated acceptance tests for projects using user centred design. There is nothing inherent in user centred design which prevents an agile approach being adopted and indeed agile adds huge value to user centred design by reducing the feedback loops […]
I read with extreme interest James Shore’s blog about FIT but was dismayed that he devalues automated acceptance testing. To claim that FIT is a “natural language” is wrong, it is a developer language and this is possibly why customers don’t get involved. Concordion on the other hand is natural language and I think plays […]
Thanks to a colleague at emergn I’m left questioning the real value of TDD.
Michael Hill has produced a lovely essay about how TDD and Pair Programming ensure that the internal quality of your code doesn’t cost you in future productivity.