The color of acceptance is gray

James Shore recently wrote some brillant words about acceptance testing:

I think “acceptance” is actually a nuanced problem that is fuzzy, social, and negotiable. Using tests to mediate this problem is a bad idea, in my opinion. I’d rather see “acceptance” be done through face-to-face conversations before, after, and during development of code, centering around whiteboard sketches (earlier) and manual demonstrations (later) rather than automated tests.

To rephrase: “acceptance” should be a conversation, and it’s one that we should allow to grow and change as the customer sees the software and refines her understanding of what she wants. Testing is too limited, and too rigid. Asking customers to read and write acceptance tests is a poor use of their time, skill, and inclinations.

This is pretty much where my head is at right now around automating acceptance tests. Automated tests are black and white, acceptance is gray.

“The color of truth is gray.”
~ André Gide

I prefer to have a handful of end to end automated functional tests that cover the typical journey of a user than a large set of acceptance tests constantly in a state of flux as the system is being developed and acceptance is being defined and changed.

We need to take feedback from the customer that we are building the right thing and ensure our automated tests model this, not make them responsible for specifying the actual tests.

Author: Alister Scott

Alister is an Excellence Wrangler for Automattic.

1 thought on “The color of acceptance is gray”

  1. James’ point of view is a quite typical one side view. If you are in development of a NEW application than it perfectly make sense ” ‘acceptance’ be done through face-to-face conversations before, after, and during development of code, centering around whiteboard sketches (earlier) and manual demonstrations (later) rather than automated tests.”

    However software development also has significant segment of maintenance development. When a small feature are added to big application it is a critical for the business to make sure a new release does not break any of user stories. For that type of development automated acceptance testing is very nice to have and can not be replaced by collaboration of any kind.
    Any in-house development in corporations most likely to fall into this category.

    You may just imagine the type of acceptance testing required for the libraries of scientific calculation methods … ;)

    Like

Comments are closed.