Terminology

There’s an excellent discussion initiated by Gojko Adzic on terminology used in association with acceptance test driven development (ATDD). It’s excellent because it’s playing with people’s mental models of what’s really going on. Getting to the essence of things. I support what’s going on there.

I need to get something out of my head though.

My problem (because I’m not convinced that anyone else shares it) is that we too often change the ‘nouns’ when we are describing what’s going on.  Work items transition from ‘idea’ to ‘feature’ to ‘requirement’ to ‘story’ to ‘example’ to ‘specification’ to ‘test’ with too much fluency for my comfort, like there is implied magic in behind the scenes. It seems we transform work items into completely different things by doing something.

Maybe we do, maybe we don’t. What I need to get out of my head is – what if we just used one noun, and described everything else as a state change?

My first candidate noun was minimal marketable feature (MMF). The challenge, however, was that an ‘automated MMF’ is, well, the solution we’re trying to specify. Didn’t work.

My second candidate was, as in the diagram above, specification. I transcribed Gojko’s terminology into a statechart. I used ‘Refined’ instead of ‘Distilled’ based on a twitter conversation I overheard between Gojko and Elisabeth Hendrickson. This seems to work better.

The ‘Executable’ state is actually a composite state that I almost labelled ‘Automated’. I only prefer ‘executable’ since it’s seems to be used more often in conjunction with my preferred noun (‘specification’) and the term ‘automated’ is more often used with a different noun (‘test’).

I wanted two states to represent the higher-level ‘Executable’ state because I know that just writing and running something in a BDD container doesn’t mean that the specification actually runs the system under development, nor does automagically get incorporated into the continuous validation system Gojko was referring to. I wanted this other state so that I could add the transition and indicate the work that still has to happen for that specification to be useful. In keeping with the spirit of Gojko’s post, the format of the specification even after this work is completed, should still be like it came off the whiteboard, that is, a literal representation of the specification.

After having done this, I believe there is value in unifying the conversation around a single noun, and I believe that the best candidate noun – for now - is ‘specification’.

Other random thoughts on this:

• Interesting that this post isn’t about testing, although testing skills certainly help in doing this.  Gojko called this collaborative specification.
• I’ve de-emphasized the design skills required to complete the transition from ‘Not Integrated’ to ‘Integrated’. Unfortunately. But I don’t want to clutter the diagram.
• My dream – presented as a lightning talk at the first Agile Alliance Functional Testing Tools workshop in 2007 – is that the literal executable specification described above (that one that appears as it did on the whiteboard) runs either inside or outside the GUI as requested at runtime. Most for ‘separation of concerns’ reasons. An easy way to validate the back end is a must, so that business rules get automated and validated first. Then it’s a second step to figure out the optimal user experience, and I would still like to use that very same specification to drive the development of that user experience.

Please continue the discussion on Gojko’s blog so that we keep the thoughts and minds directed in a single place.