Acceptance Tests – Best Practices

One area where agile methodology often gets criticised is lack of emphasis on documentation, by teams long used to written word in order to specify and validate customer requirements. Agile associate higher value to interactions (over documentation) & one of the key mechanisms for enabling interaction is Acceptance Test.

Acceptance Tests are part and parcel of Stories – and often written on the same piece of paper as the Story itself (For distributed teams likely to be part the same record or ‘issue’ on the backlog management tool).

The importance of good acceptance tests as an enabler for interaction between PO & Developers (including specialist QA members of the team) & requirement elicitation tool can often be overlooked. It is easy for PO to create bunch of Stories and team to infer from those details, and although demos provide an useful feedback mechanism to the team, it could lead to crucial time being lost in developing something which was not needed.

Even with teams that do write these tests – these are often written as statements which can be open to interpretations – leading to outcome no different from one where there were no tests were provided at all.

So, how do you get the best out of your acceptance tests –

  • Firstly by ensuring that PO ‘always’ write acceptance tests separately to the Story details
  • If you are using a backlog management tool, it helps to have acceptance tests as separate issue, for couple of reasons – To ensure that PO captures and provide tests to the team & to look at the effectiveness of these over a several sprints/a release
  • Ensuring that team use these during Sprint planning for story elicitation
  • Team works with PO to bring out specific criteria if s/he is unable to provide that upfront or criteria needs negotiation with multiple steps if needed – remember that the goal (and process to set them) need to be pragmatic
  • Tests are always written in business domain language and as YES/NO questions, so that the verification is straightforward & accurate
  • If you are doing TDD, ensuring that these inputs are fully captured in the automated test cases – more on TDD later
  • And last but not least – always use the Sprint Retrospectives to talk about good and bad examples – so you keep improving these