Elisabeth Hendricksson stated at Turku Agile Day 2010 that “Specs is an abbreviation for speculations”. She is right, specs are often speculations. How can this be avoided? Execution of code doesn’t leave any room for speculation. If the specs can be executed, they aren’t speculations anymore.
Specifications can be expressed in many different ways. One popular form is as Word documents. Word documents are hard to execute, they need to be interpreted and the writer’s intent may be lost in translation. It would be nice to remove the risk of misinterpretation and the risk of losing the authors intent during translation. This can only be done if no interpretation takes place and no translation is done. The solution is obviously to create specifications that can be executed.
If we want to execute a specification, do we not have to write a program to do so? If the customers could write the program, then they wouldn’t need us do it for them and the initial problem would not even exist. The answer is no, they don’t have to write a program. They only need to express themselves so the expression can be used in an execution later.
I will show you a way to express what your want, in a formal way, so that it can be used as the basis for an execution. The customer only need to be able to express what they want in a few sentences in their natural language of choice. This description will be translated into something that is actually executable:
Given a system setup in a particular way
When something is executed
Then the result is expected to be a new state of the system
This formal way of expressing yourself can be translated and used as the basis for an execution of the system under test. This presentation will give you more details about the why, an example of how (executed live of course) and finally some potential drawbacks. You may not know all details after this session, but you will know that it can be done and how it can be done.
Watch the video on http://www.infoq.com/presentations/Executable-Specifications
