Gojko Adzic

As a community, we’re very guilty of using technical terms and confusing business users. If we want to get them more involved, we have to use the right names for the right things and stop confusing people. This lesson is obvious in acceptance tests and we know that we need to keep the naming consistent and avoid misleading terms, but we don’t do this when we talk about the process. For example, when we say continuous integration in the context of agile acceptance testing, we don’t really mean running integration tests. So why use that term, and then have to explain how acceptance tests are different from integration tests? Until I started using Specification Workshops as the name for a collaborative meeting about acceptance tests, it was very hard to convince business users to participate. But a simple change in naming made the problem go away. Continue Reading »

Creating an Executable Specification from existing manual test scripts might seem as a logical thing to do when starting out with Specification by Example and Agile Acceptance Testing. Such scripts already describe what the system does, and the testers are running them anyway, so automation will surely help. Not really — this is in fact one of the most common failure patterns. Continue Reading »

The long term benefits of agile acceptance testing come from live documentation – a description of the system functionality which is reliable, easily accessible and much easier to read and understand than the code. In order to be effective as live specification, acceptance tests have to be written in a way that enables others to pick them up months or even years later and easily understand what they do, why they are there and what they describe. Here are some simple heuristics that will help you measure and improve your tests to make them better as a live specification. Continue Reading »

David Evans and I facilitated a session on designing a killer agile test management tool last week at the UK Test Management Forum, with the goal of learning what are the biggest currently unsolved problems for agile teams in the area of testing at the moment. So for any tool vendors our there, here are the ideas.

We ran a variant of the Product Box game, described by Luke Hohmann in Innovation Games: Creating Breakthrough Products and Services, with five teams competing to design the best agile test management tool. They gave their products the following names: Silver Bullet, Agile Manager, Perfect 10, Nimble and FleXT. Continue Reading »

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 »