Selling executable specifications to stakeholders, testers and developers

In this post I want to share how we made a breakthrough in using executable specifications in our latest project.

Executable specificationsExecutable specifications are scenarios created by developers, testers and stakeholders working in collaboration that check the behaviour of a system every time code is committed. For more information and a podcast about Executable specifications check out this Hanselminutes episode ‘Executable Specifications with Gojko Adzic, Jonas Bandi and Aslak Hellesoy’.

The need for change

A few months ago after joining the team, there was a lot confusion how a previous project worked.

Stakeholders weren’t sure what functionality had been implemented, testers weren’t sure if everything had been tested and developers didn’t want to go anywhere near the code.

While there was a wiki no one was sure if was 100% accurate which meant it could do more harm than good because it could lead to false assumptions.

As a result of this the relationships between the groups had suffered.

Inspired by Dan North’s talk ‘How to sell BDD to the business’ I suggested using BDD (behavior driven development) and executable specifications to help prevent this happening in the future.

Testers and business owners were open to the idea but were skeptical to how valuable it would be.

So we decided to try it out on a small part of the project.

And it worked!

Working collaboratively we found relationships started to improve and there was a lot more trust between the groups.

TickAt the end of the project stake holders, testers and developers agreed executable specifications were an excellent way to develop software and keen to adopt the approach for other projects.

So what sold executable specifications to the stakeholders, testers and developers?

  • Scenarios that matched the business problems the stakeholders wanted to solve.

    This gave stakeholders confidence and lowered fear and resistance to change.

  • Easy to read scenarios that matched the domain language the stakeholders were using.

    Stakeholders could relate to scenarios and therefore felt involved.

  • Using scenarios to fill out the blanks.

    When the test team or developers found new scenarios they communicated using with stakeholders leaving out what should happen (the then step) for them to fill in.

  • The use of tables.

    Tables allow the reader to visualise the data, reduce reputation and mean you don’t have to cram in lots of words.

    For example instead of having

    Scenario: Submitting form with invalid password displays error
  Given I am on the registration page
  When enter the password 'a'
  And submit the form
  Then I should see the message 'Passwords must be 8 to 16 characters long and include at least one capital letter, one lower case letter, and one number'

    and then repeating this for every permutation of invalid passwords, you can do this

    Scenario: Entering an invalid password displays error
  Given I am on the registration page
  When enter the password
    | a						|
	| aaaaaaaa				|
    | AAAAAAAA				|
	| aaaaAAAA				|
	| 12345678				|
	| 1234567A				|
	| 1234567a				|
	| 12345678aaaaaaaaA		|
  And submit the form
  Then I should see the message 'Passwords must be 8 to 16 characters long and include at least one capital letter, one lower case letter, and one number'

    We found this gave us valuable input from stakeholders and testers who were able to come up with scenarios much faster than before.

  • Living documentation.

    Running tests to ensure the scenarios still reflected the behaviour of the system after every code change meant documentation was reliable and accurate.

The future

I’m pleased stakeholders, testers and developers have recognised the value of using BDD, scenarios and executable specifications.

By taking small steps, inspecting and adapting along the way, I hope that more projects I work on can adopt this approach.