Writing Executable Specifications

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


Why Learning Product Organizations Experiment Frequently

Many organizations are afraid of designing and running experiments for product development. Validation of the assumption approach has not been widely spread in the industry as a standard. Hypotheses are taken as facts and they are turned into requirements and features without verification. In contrast, other companies seem to be more customer value-oriented and validate […]

Read More

Designing a Scalable Product & Engineering Methodology

Are you bored by hearing about Spotify’s Model, Basecamp’s Shape Up, or Netflix’s “No Rules Rules”? All of them do have something in common. They tailored something unique to match both their ambition and their strengths, while honestly acknowledging their weaknesses.

Read More

Design Thinking Activities

This video explains that the six stages of the design thinking process can be supported by a very wide range of UX methods and activities. Don’t limit yourself to the most commonly mentioned methods.

Read More

Copyright © 2009-2022 Martinig & Associates