Skip to main content

Why Specification by Example?

Quite a lot of the time there is, should we say healthy debate within the project team when not everybody has the same opinions. And let's admit nobody ever has the same opinions of how software will or should be developed. 

I take this from recent personal experience and really wanted to highlight my view on this technique. 

I wanted to try and clarify some misunderstandings about what project teams are trying to achieve. 

As a team we are attempting to:
  • Create a shared understanding of the behaviour of the system to fulfil a user story by using specific, concrete worked examples to illustrate the required behaviour for a range of situations
  • Collaborate so that people provided their expertise and viewpoints on a story on the basis that different perspectives allow us to better consider what is required. As our Teamwork value says we are “better together than we are individually"
  • Create these examples in a format that can be shared between, and understood by, all members of the project team, both technical and non-technical – for example, business stakeholders as well as testers and developers

The benefits of this approach is that we:
  • Address ambiguity, misunderstandings and assumptions at the earliest point in the development lifecycle, i.e. before any code has been written. This is because it is cheaper and quicker in the long run to address this issues before we have wasted time building and testing the wrong things
  • Make sure we take into account the requirements from different stakeholders within the business – for example Security, Support teams etc – and also that we take into account what the current systems do so that we can achieve consistency, where applicable, rather than one person making up what they think the system should do

It is incredibly difficult for one person to fully define how a system should behave, even for a story, with all the various alternate paths the system could take, and be able to communicate this in a clear and consistent manner to all the people involved in the project. Working as a team will spark healthy conversations in order to define exactly what the business want.

In a meeting I chaired we seemed to end up in a discussion around the implementation of tests within the project, and this seemed to take a low-level, developer-centric approach. To me this is a separate issue, the key issue is that we need to look at what we want to develop and test, not how we are going to test it.

One advantage of writing our examples in a specific format – using a Given, When, Then syntax – is that it gives us the option to automate this using a tool such as SpecFlow but that doesn’t mean that other test tools aren’t available for us to use, whether that is a unit test framework, Fitnesse or DBFit, SoapUI or Selenium. However, another advantage of using this format is that it forces us to write them in a clear and consistent manner which helps us to communicate with all members of the project team, including non-technical ones, in a manner that a unit test suite never could. That doesn’t mean that we can’t write unit tests when we’re writing the low level code but we need to understand what our unit tests should be testing.

A key word to take from this is "Collaboration" this is what Specification by Example is all about. 


Popular posts from this blog

My Testbash Brighton 2017 Notes

This was my second Testbash... if you ever get the chance in the future these conferences are a must!
I took copious amounts of notes from the 9 talks and tried to highlight my key takeaways here... hope they make sense but please comment if you have any questions :-)
Amy Phillips - Continuous Delivery
A survival guide to joining a fast paced environment/project…
Where does testing fit within Continuous delivery:

As highlighted, basically from start to finish…
There are lots of things we can do when joining a project that is using Continuous Delivery but one of the main points from this talk was to do your research! There should be an element of "Continuous" in every aspect of the project.
·Learning the ling, what's the difference Continuous Delivery, Continuous Deployment, Continuous Integration, Continuous design, Continuous Improvements etc.? ·Understand what your role in the project is going to be ·Understand the teams values, What's going well and maybe what the team p…

Is TestBash an Invaluable experience?

Over the last few years, I’ve attended four single track conferences at TestBash Brighton and Manchester. Most recently, September 2018 and April 2019.

One of the most common questions I get after the conference is, Was it worth it? Especially now given, I’m a contractor, and I attend at my own expense.

In short, Yes It’s definitely worth the trip!

That leads me into my question; does a single-track conference work for me, or could I get more out of TestBash?

Of course, there are pros and cons, some talks may not be as engaging, but this is no disrespect to the speakers, for me, it’s because I probably favour certain subjects and I’m pretty sure others will think the same.

Do I make the most of what’s on offer at TestBash? It pains me to say, No! I don’t make the most of the events leading up to and post the single-track conference so I could get more from the week.

TestBash offers master classes on automation. A full day of workshops. Test.bash() with talks on automation and technica…

The way we work shouldn’t be ‘Alien’ anymore, Should it!?!?

It’s been a good while since I have written anything (Mainly because I’m not that good a writer) but given my 16 months in the public sector I thought it was time… 
For a good number of years now the DevOps trend has given rise of buzzwords and methods aiming to speed delivery and it’s now an assumption of mine that most organisations are au fait with the term ‘Continuous Delivery’.
I was wrong…
Within the organisation that I am currently placed I believe I have a high-functioning collaborative team who work flexibly and in continuous cycle. We also involve the users which is a huge benefit to the development teams, but that’s not saying we get everything right 100% of the time! Teams must continue to learn and evolve to remain productive.
Our team work in one of several delivery groups and with this comes multiple challenges; Silos No single environment strategy lack of communicationsVaried ways of working.  And thats just to name a few, which is interesting when all delivery groups …