This conference has finished. Go to the main OpenAgile website to find out about upcoming conferences.

Intro @ Open Agile Romania 2011: Build a Great Team

Andrea Provaglio: Talk on Effective Self-Organization

Jurgen Appelo: Talk on How to Change the World

Open Space Sessions & Planning Poker Cards Prize

Thomas Sundberg

Thomas Sundberg

Thomas Sundberg is a consultant at Waymark based in Stockholm, Sweden. He has a Masters degree in Computer Science from the Royal Institute of Technology, KTH, in Stockholm. Thomas has been working as a developer for more than 20 years. He has taught programming at The Royal Institute of Technology, KTH, one the leading technical universities in Sweden.

Thomas has developed an obsession for technical excellence. This translates to Software Craftsmanship, Clean Code and Test Automation.

Thomas is also a speaker at different conferences and developer venues, including eXtreme Programming XP, Agila Sverige, Oredev, Turku Agile Day, Agile Central Europe, GeeCON, Java Developer Day, Agile By Example, Scandinavian Developer Conference, Agile Testing Days, Agile Cambridge and Open Agile Romania.

Thomas runs a blog where he writes about programming, Software craftsmanship and whatever problem he wants to share a solution about. It can be found at

Twitter: @thomassundberg

Talk: Behavior Driven Development

Elisabeth Hendricksson has stated 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 speculations. 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 writers intent may be lost in the translation.

It would be nice to remove the risk of misinterpretation and the risk of losing the authors intent during the 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 you 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 about BDD and Executable Specifications after this session, but you will know that it can be done and how it can be done.

BDD, Automated testing, Executable Specifications, Specifications by Example