More about acceptance tests

Coming back to the definition of done, I wanted to spend a couple more words about testing.

What does it mean that the working software is the primary artefact?

It means that if you spend two years finalising the requirements documentation for a 5-years project, you did not accomplish 40% of the work: you accomplished nothing.
Even if you started to develop or if you finished it but is not working, you still do not have anything.
It sounds sort of unfair, maybe you are really very close to have something working but this is all the point.

The artefact you need to produce at the end of every iteration is a working product: it needs to pass the acceptance tests.

And what are acceptance tests?

Remember from the product backlog, they are associated to each release.

And they can be broken down, until the atomic tasks: every task is not done if it has not passed the related acceptance test. We want to develop working products. The principle here is getting to done, either in flow or iterations.

The point of using agile is to get finish something valuable-to-the-business quickly, to get feedback. So you can use the feedback to change, being your project, your portfolio, your priorities. Agile is all about change.

One last thing is that testing is the hardest part and what are appropriate acceptance tests vary a lot: it depends if you develop web app or boxed software or embedded software or critical software.

If the project is complex / critical / composed of multiple parts you may need some extra testing phase – such as an integration or system test – or even external testing teams to validate its quality.

In this cases there are a couple of strategies that you can put in place (again, this depends on the type pf project and challenges and your experience):

  • you can add special “validation” releases to the plan, maybe one every three iterations, depending on the effort of the extra testing phase.
  • you can change the mix of the iterations during the acceptance phase (i.e. it could be a 50% development of features for next iteration and 50% for bug fixing) or even plan a parallel iteration that will take care of the critical bugs found.

Leave a comment