Gojko Adzic

Here’s a video from a joint workshop that David Evans, Mike Scott and I organised yesterday at Skills Matter. We talked about strategies to get the most out of acceptance tests (especially with FitNesse) and organised a group workshop to review some good and bad examples of acceptance tests – taken from my Hands On Acceptance Testing workshop.

While doing research for my new book, I was very surprised to find out that Jim Shore gave up on acceptance testing. I use his “describe-demonstrate-develop” process description all the time in my workshops, so I guess I better stop doing that. Jim Shore wrote:

My experience with Fit and other agile acceptance testing tools is that they cost more than they’re worth. There’s a lot of value in getting concrete examples from real customers and business experts; not so much value in using “natural language” tools like Fit and similar.

The two failure patterns that Shore describes in his post are falling back on testers to write everything and merging acceptance and integration tests. I’ve experienced both of these myself, and it seems that they are common in general. We discussed both during the top 10 ways to fail with acceptance testing openspace session at CITCON Europe last year. However, there are good ways to solve both problems. Continue Reading »

I got this question from a reader today:

How would you effectively define a sufficient set of If-When-Then scenarios to test for correctness what is potentially an extremely large set of transformations?

Continue Reading »

I got this question today from a blog reader:

They are thinking about using Concordion here. I remember you made some comments about using it. Can it be used sensibly by a tester without lots of dev experience?

Concordion is a great tool for acceptance testing as support for development. Whether it can be used sensibly by a tester without lots of development experience, that depends on what the intended use is. Concordion tests/results are HTML files, so anyone can read them using a browser. I’ve never tried to write Concordion tests using Word or anything similar, only by hand-coding HTML, so I don’t know whether tests can be maintained with a visual tool. However, anyone with basic HTML knowledge should be able to write tests as well. In terms of running the tests, Concordion runs within JUnit/NUnit, so this should be fairly simple as well.

Concordion does not have a test management tool and intentionally doesn’t allow you to reuse or share automation components, so it requires a fair bit of cooperation between developers and testers. I think this is very good for tests that support development, but it might be a problem for retro-fitting regression test packs into an existing product if testers are expected to do the bulk of work.

I wrote a review of concordion last year, which will give you a bit more detail on how it works. I also have a short video about it (.NET oriented but still a good introduction to capabilities):

David Peterson, the author of Concordion, spoke about it at the agile acceptance testing tools round-up event, and that video is also online.

I facilitated an openspace session on acceptance testing and collaboration between business people, developers and testers at CITCON Europe last week. We started with a list of five common reasons why I’ve seen teams fail with acceptance testing but added five more during the discussion, so here’s an expanded top 10 list:

Continue Reading »