Category Archives: BDD/ATDD

Old Favourite: Radio by Example

This first appeared on my old blog in  “2008 under the title Specification by Example”. I’ve made a couple of minor refinements to the text and I’ve added the image below from the 2009 “GOOS” book .

Internet radio‘ has come a long way since it first began. Long gone are the days where you have to seek out an online station that streamed a preselected playlist with mostly music that you like, or several stations for those with more eclectic taste. Instead, services like Pandora.com and Last.fm create a personalised radio station that matches the user’s own personal taste.

These personalised internet-radio stations are far more sophisticated than just specifying what genres and styles you like. When they first started you didn’t do that at all. When last.fm first started you provided an example of a song that you like. Software analysed the song finding common aspects of the music’s ‘DNA’ – including genre, tempo, how melodic it is and countless other sound characteristics in their database. From this they create a user-specific internet radio station that matches the users taste. As you listen, you give them feedback saying which songs you love and which ones you hate. Your future play-lists are refined with each piece of feedback you provide. This feedback is in itself more examples of songs that do and don’t match your taste. As a result you’d find yourself listening to songs you’d not have otherwise discovered.

That is Specification by Example! The product (in the above, your personal playlist) evolves by inferring the desired rules and characteristics from concrete examples.

And, as several have been saying for years… Test Driven Development is just that – Specification by Example – applied to software development. Instead of examples of songs, we provide examples of what we’d like the product, or part thereof, to do. These examples take the form of tests. It so happens that the evolution of the software product is performed by humans, unlike the internet playlist evolved by a machine.

Write a failing acceptance test, then cycle over writing a failing unit test, making that pass, and refactor repeating until the acceptance test passes.

Software Pottery

“Building software” is a phrase I hear used time and again. Indeed, many do still think of software development as akin to construction.  Modern (agile) software development doesn’t feel like that to me. There was a time, like the construction architect, when we had to increment and iterate on paper and in models. The cost of computing was too high to do such iteration inside the machine. The cost difference between making a small change in our understanding and reflecting that in the actual product was too great. The cost of change meant that we had to treat the creation of software like constructing buildings or bridges. But those times are, or should be, in the past.

To me, modern (agile) software development feels more like pottery. But, instead of ‘throwing clay’ we throw our consciousness, in the form of electrons flowing over silicon, onto a spinning wheel of user-story implementation cycles.

Picture of a pot being created and evolved on a pottery wheel.

Source: http://www.flickr.com/photos/kellinahandbasket/2183799236

We evolve our understanding of what our customer wants with each conversation. We reflect that understanding by evolving the product’s shape as we touch the outer surface with each new automated acceptance test (or example scenario). We evolve its structure as we touch the inner surface with each new unit test (or unit specification). We keep it supple as we moisten it with each refactoring. Our customer looks on, gives us feedback and we start the next revolution of the software development wheel. Never letting the product dry and harden; keeping it flexible, malleable, soft(ware).

There is nothing that feels like construction here. I never feel like I’m “building” something. Much more like I’m evolving my understanding, evolving the product, evolving my understanding again and so on.

For these reasons l am not comfortable with referring to this process as “building”. I’m also not comfortable calling it “throwing” (as in pottery).

I am very comfortable calling it “development”. I use the word “develop” in terms of its literal meaning:

to bring into being or activity; generate; evolve.
-dictionary.com

From the first thought of a new idea, through each conversation along the way, to each revolution of the software development wheel, I develop products.

I don’t “build”.

I create. I make. I shape. I evolve.

—————————
Footnote: I’m not aware of anyone drawing this analogy before. If you have heard or read someone explain it in this way before now, please let me know.

GhostDriver – Headless Selenium RemoteWebDriver

GhostDriver is a Selenium server that can be connected to via a RemoteWebDriver.

It runs completely heedlessly on PhantomJS but still behaves (mostly) like a typical webkit browser. By avoiding the overhead of actually rendering the page in a GUI it can run standard Selenium tests noticeably faster and on a headless build server too.

This is especially beneficial if you want to use continuous testing IDE plugins like Infinitest or JUnitMax or simply to encourage developers to run end-to-end tests more frequently.

GhostDriver is written on top of PhantomJS, a headless WebKit browser which uses QtWebKit.

It’s already 35%-50% faster than ChromeDriver despite the fact that QtWebKit has the standard WebKit Javascript engine. QtWebKit is moving to the V8 JS engine (as used in Chrome) which means it’s only going to get faster…

It’s still work in progress and hasn’t implemented the entire Selenium wire protocol yet but it’s certainly one to watch.

Presentation at SeleniumConf 2012: http://www.youtube.com/watch?v=wqxkKIC2HDY

Find it on GitHub: https://github.com/detro/ghostdriver/

Implemented by: Ivan De Marino

Scenario-Oriented vs. Rules-Oriented Acceptance Criteria

Acceptance Criteria, Scenarios, Acceptance Tests are, in my experience, often a source of confusion.

Such confusion results in questions like the one asked of Rachel Davies recently, i.e. “When to write story tests” (sometimes also known as “Acceptance Tests” or in BDD parlance “Scenarios”).

In her answer, Rachel highlighted that:

…acceptance criteria and example scenarios are a bit like the chicken and the egg – it’s not always clear which comes first so iterate!”

In that article, Rachel distinguishes between acceptance criteria and example scenarios by reference to Liz Keogh’s blog post on the subject of “Acceptance Criteria vs. Scenarios”:

where she explains that acceptance criteria are general rules covering system behaviour from which executable examples (Scenarios) can be derived

Seeing the acceptance criteria as rules and the scenarios as something else, is one way of looking at it. There’s another way too…

Instead of Acceptance Criteria that are rules and Acceptance Tests that are scenarios… I often find it useful to arrive at Acceptance Criteria that are scenarios, of which the Acceptance Tests are just a more detailed expression.

I.e. Scenario-Oriented Acceptance Criteria.

Expressing the Intent of the Story

Many teams I encounter, especially newer ones, place higher importance on the things we label “acceptance criteria” than on the things we label “acceptance tests” or “scenarios”.

By this I mean that, such a team might ultimately determine whether the intent of the story was fulfilled by evaluating the product against these rules-oriented criteria. Worse still, I’ve observed some teams also have:

  • Overheads of checking that these rule-based criteria are fulfilled as well as the scenario-oriented acceptance tests
  • Teams working in silos where BAs take sole responsibility of criteria and testers take sole responsibility for scenarios
  • A desire to have traceability from the acceptance tests back to the acceptance criteria
  • Rules expressed as rules in two places – the criteria and the code
  • Criteria treated as the specification, rather than using specification by example

If we take the approach of not distinguishing between acceptance criteria and acceptance tests (i.e. see the acceptance tests as the acceptance criteria) then we can encourage teams away from these kinds of problems.

I’m not saying it solves the problem – it’s just easier, in my experience, to move the team towards collaboratively arriving at a shared understanding of the intent of the story this way.

To do this, we need to iteratively evolve our acceptance criteria from rules-oriented to scenario-oriented criteria.

Acceptance Criteria: from rules-oriented to scenario-oriented:

Let’s say we had this user story:

As a snapshot photographer
I want some photo albums to be private
So that I have a backup of my personal photos online

And let’s say the product owner first expresses the Acceptance Criteria as rules:

  • Must have a way to set the privacy of photo albums
  • Private albums must be visible to me
  • Private albums must not be visible to others

We might discuss those to identify scenarios (as vertical slices through the above criteria):

  • Create new private album
  • Make public album private
  • Make private album public

Here, many teams would retain both acceptance criteria and scenarios. That’s ok but I’d only do that if we collectively understood that the information from these two will come together in the acceptance tests… And that whatever we agree in those acceptance tests supersede the previously discussed criteria.

This understanding tends to occur in highly collaborative teams. In newer teams, where disciplines (Business Analysts, Testers, Developers) are working more independently this tends to be harder to achieve.

In those situations (and often even in highly collaborative teams) I’d continue the discussion to iterate over the rules-oriented criteria to arrive at scenario-oriented criteria, carrying over any information captured in the rules, discarding the original rules-based criteria as we go. This might leave me with the following scenarios:

  • Create new private album (visible to me, not to others)
  • Make public album private (visible to me, not to others)
  • Make private album public (visible to me, & others)

Which, with a subtle change to the wording, become the acceptance criteria. I.e. the story is complete when we:

  • Can create new private album (visible to me, not to others)
  • Can make public album private (visible to me, not to others)
  • Can make private album public (visible to me, & others)

Once the story is ‘in-play’ (e.g. during a time-box/iteration/sprint) I’d elaborate these one at a time, implementing just enough to get each one passing as I go. By doing this we might arrive at:

Scenario: Can Create new private album
When I create a new private album called "Weekend in Brighton"
Then I should be able to see the album
And others should not be able to see it

Scenario: Can Make public album private
Given there is a public album called "Friday Night"
When I make that album private
Then I should be able to see the album
And others should not be able to see it

Scenario: Can Make private album public
Given there is a private album called "Friday Night"
When I make that album public
Then I should be able to see the album
And others should be able to see it

By being an elaboration of the scenario-oriented acceptance criteria there’s no implied need to also check the implementation against the original ‘rules-oriented’ criteria.

Agreeing that this is how we’ll work, it encourages more collaborative working – at least between the Business Analysts and Testers.

These new scenario-based criteria become the only means of determining whether the intent of the story has been fulfilled, avoiding much of the confusion that can occur when we have rules-oriented acceptance criteria as well as separate acceptance test scenarios.

In short, more often than not, I find these things much easier when the criteria and the scenarios are essentially one and the same.

Why not  give it a try?

Old Favourite – Sharks, Debts, Critical Mass and other reasons to Sustain Quality

This article originally featured on my old blog on 18th January 2010.

A while back I tweeted about critical mass of software:

Critical Mass of Code – past which the changeability of the code is infeasible, requiring that it be completely rewritten.

An elaboration of this might be:

Critical Mass of Software: the state of a software system when the cost of changing it (enhancement or correcting defects) is less economical than re-writing it.

This graph illustrates a hypothetical project where the cost of change increases over time (the shape of which reminds me of a thresher shark):

Note:The cost of a rewrite gradually grows at first to account for the delay between starting the re-write and achieving the same amount of functionality in the original version of the software at the same point in time. The gap between the cost-of-change and the cost-of-rewrite begins to decrease as the time it takes to implement each feature of comparable benefit in the original version grows.

It was just one of those thoughts that popped into my head. I soon discovered that critical mass of software is not a new idea.

One opportunity that I feel organisations miss out on is that this can be used as a financial justification for repaying technical debt, thus preventing or delaying the point at which software reaches its Critical Mass, or avoiding it altogether.

Maintaining quality combined with practices that keep the effort involved in completing each feature from growing over time can defer critical mass indefinitely:

Note: The cost of a rewrite is slightly less at first assuming that we are doing a little extra work to ensure that we get the infrastructure we need up and running to support sustainable change (e.g. continuous integration etc.)

This flat cost of change curve is one of the motivations of many agile practices and software craftsmanship techniques, such as continuous integration, test-driven-development, behaviour driven development and the continuous refactoring inherent in the latter two. A flat cost-of-change trend is good for the business, as they have more predictable expenditure.

The behaviour I’ve noticed with some teams is to knowingly accrue technical debt to shorten time to a near-future delivery in order to capitalise on an opportunity and then pay it back soon after:

This certainly defers reaching critical mass but it doesn’t prevent it.

Unfortunately, I see more teams taking on technical debt and not repaying it (for various reasons, often blamed on “the business” putting pressure on delivery dates).

If we had a way of estimating the point at which we’d reach critical mass, we’d be able to compare the benefit of repaying technical debt now in order to avoid or delay the cost of a rewrite… or even better, demonstrate the value of achieving a flatter cost of change.

I’m not sure that we have the data or the means of predicting it, but perhaps these illustrations of a hypothetical scenario will help you explain why sustaining constant quality, automating repeatable tests (or checking as some prefer to call it) wherever technically possible and, on those occasions when we do need to make a conscious choice to compromise quality to capitalise on an opportunity, that the debt is repaid soon after.

One company I know reached this point a couple of years ago and embarked on a department wide transformation to grow their skills in agile methods so that they not only re-wrote the software but could also avoid ever reaching critical mass again. A bold move, but one that paid off within a year. Even for them, they’ll need to avoid complacency as time goes on and not forget the lessons of the past. Let’s hope they do.

Old Favourite – Developer Race-Tech: Continuous Testing

The original version of this article appeared on my old blog on 28th April 2010. This version has had some edits…

Gearboxes in competitive motor racing are designed to shift as fast as possible. A competitive race-car has computer controlled, hydraulically activated gear shifts that change gears up or down faster than you can blink (literally)! In Formula One, each shift is so fast that the gearbox systems have been dubbed “seamless shift” gearboxes and can shift gear in around 2-4 100ths (0.02 – 0.04) of a second. Compare that to the circa 1-2 second gear-shift a competent driver takes to manually de-clutch, change gear and re-clutch on a road car. Even automatic gearboxes on road cars can’t keep pace with the rapid gear changes that a race car delivers.

Competitive Edge

The race car is only saving fractions of a second with each accelerated up-shift, but the race-driver changes gear so often per lap and there are so many laps in a race that these fractions of a second can add up to a vital and significant lead over their competitors.[1]
mclaren-mercedes

Set aside the lap-time improvements for a moment from spending at least half a second more on the power per up-shift than with a manual box… The modern F1 driver has much more to do in the cockpit too than the comparative tedium of changing gear [2].

Developer race-tech

Now, in motor racing, such gearboxes are taken for granted. No serious Formula One racing team would put their car on the track without one.

In a world where a lot of software development is for companies competing in the economical equivalent of a race, it seems that development teams aren’t taking full advantage of their own metaphorical millisecond gear-shifts.

There are tools that are a developer’s equivalent of a racing gearbox. The simplest example is background compilation. Other examples are refactoring tools that make widespread changes with a simple key-stroke. What once took minutes or hours with global find & replace or even scripting, we can complete in seconds. IDEs that automatically complete class-names and method names are another example. These are tools that many of us take for granted, like the racing driver and automated gear-shift.

Falling behind

But there are other places where we are still not taking full advantage of the technology. I am still encountering surprisingly few people using continuous testing tools, where tests are run automatically in the background every time a file is saved, and not just the test I’m working on, all my tests. There are a few tools available for this, including Infinitest and ZenTest.

Despite the availability of such tools, I still see many developers using keyboard shortcuts to execute tests. Or, worse, reaching for the mouse, right-clicking, navigating another menu level down and running the tests with a left-click, or worse still, forgetting to run them altogether. I want rapid feedback with minimum friction to obtaining it. Much like background compilation, unit tests should just run, and run often, alerting us when a problem occurs. The easier they are to run, the more likely we are to run them… How much easier could it be than it happening automagically each time we save a file?

Need for Speed

Try it for a while and, like me, even keyboard-shortcut executed tests start to feel like you’re stuck in traffic rather than being in a competitive race to the finish… Or, maybe it’s just me and my need for speed

 

The video is of me on the Silverstone Southern Circuit (part of the F1 GP circuit) taking my UK National Class B Racing License Test in a Nissan R35 GTR – approx 480+bhp, 0-62mph (0-100kmh) in 3.5secs, using it’s double-clutch, paddle-operated gear-shift providing gear changes in about 0.2 of a second. I passed… despite being very cautious on the brakes… and was noticeably quicker than the other person doing their test… which you see towards the end as I pass them :-)

[1] At the Monaco GP, an F1 driver will change gear around 50-60 times in one lap. Over 78 laps, this adds up to as many as 4680 gear changes over the whole race (up and down-shifts).

[2] The comparative tedium of de-clutching, shifting and re-engaging the clutch is something that a race-driver should not need to worry about as they approach 200mph while adjusting the brake-balance lever, switching to a new fuel-air mixture setting, pressing the KERS boost button and/or deactivating the Drag Reduction System.

 

Photo of the github page

Cucumber – with step-free access

A while back I wrote about writing feature specs (acceptance tests) at the right level of abstraction. I explained how we want to pitch our scenarios at the “task” level…

Goal: What we’re trying to achieve which has one or more…
Tasks: The high-level work-item that we complete to fulfil the goal, each having one or more…
Actions: The specific steps or interactions we execute to complete the task.

I showed how many scenarios (acceptance tests) are pitched at too low a level. They’re often at the action level, detailing every field filled in and every button clicked. This is too low-level.

Instead, we want to express the business process… the tasks involved in fulfilling a goal. The actions should be expressed in the code (or step-definitions), not the plain-text scenarios. Pitching the scenarios at the action level makes scenarios much harder to maintain – especially when the user-interface changes. But, perhaps more importantly, they don’t express what’s of interest to the business.

There are other challenges faced by teams using cucumber:

  • Over-wordsmithing scenarios
  • Limited regular-expression expertise
  • Unmaintainably large step-definition files
  • Fragmented step-definition files
  • Coverage vs. Speed tradeoffs of running scenarios through or below the GUI (respectively)

We’ve taken many of the lessons we’ve learned using BDD tools to address these problems and begun to distill the various heuristics and design ideas (patterns) that emerged into a single open-source extension to cucumber – cukesalad.

Photo of the github page

Many of the heuristics and design ideas expressed in the project can be used on your existing projects without using cukesalad:

  • Treat each step-definition as a class of task. Like other classes, have one file per step-definition and organise them so they’re easy to find. Name each file using the text used in the scenario.
  • Screen Capture of Task folder Hierarchy

  • Abstract the API that drives your application behind something representing the role or type of role involved in the story
  • Write scenarios like a narrative for someone in the role relevant to the user-story
  • Write the actions within the task (or step-definition) as if they’re instructions on how to complete that task
  • And more…

Cukesalad is the ongoing expression of us mercilessly refactoring a ‘typical’ Cucumber project. At the moment, it is more of an illustration of the concepts and ideas… but some are already using it on their day-to-day projects. Check it out… try it out… and let us know what you think.

Go to http://cukesalad.info – for more info, or checkout the talk I gave at CukeUp, hosted at SkillsMatter.

And if you’re wondering why it’s called cukesalad… It’s cucumber, washed and ready to eat.

 

Old Favourite: Feature Injection User Stories on a Business Value Theme

This originally appeared on my old blog in May 2010

Feature Injection, an approach to Agile Business Analysis created by Chris Matts, is a much misunderstood thing –. It is a way of combining several techniques to understand just enough of a business problem to start expressing solutions to it. It provides specific techniques to incrementally and iteratively comprehend each of the following:

  • The business value sought (the why)
  • The problem domain (what specifically needs solving to deliver that value)
  • The resulting roles, incentives and product capabilities (the solution)

Basically, it helps us to evolve everyone’s understanding of the business-need as we (by other means) also evolve the implementation of the product.

Now, before you say, “it’s nothing new”, Chris Matts will be the first to agree. He’s taken his experience of various techniques, combined several of them that often work, evolved it into an approach to agile business analysis and given it a name.

I wish I could explain all of this now, but we’ll have to save that for another day. This post is intended to try to explain the relationship between Feature Injection and User Stories.

I’ve seen several examples of user stories taking some inspiration from Feature Injection, however, I’m not sure any of them do Feature Injection enough justice.

A common story

One of the problems with how User Stories are often applied is that people focus on the role, the capability and then try to work out what the benefit is. This is quite natural, explained nicely by Udi Dahan:

Users ultimately dictate solutions to us, as a delta from the previous set of solutions we’ve delivered them. That’s just human psychology
– writer’s block when looking at a blank page, as compared to the ease with which we provide ‘constructive criticism’ on somebody else’s work

This is something that other aspects of Feature Injection actually help you to solve… but again, today I’m just focusing on user stories…

The tendency of people to dictate solutions, rather than the problem that needs solving, has lead some to emphasise that we should put the benefit of the story first. For example, let’s say a fictional printer manufacturer consistently entices 3% of everyone they e-mail, reminding them to check their ink-levels, to purchase print consumables. In this situation, some might illustrate taking a story like this…


As the PrintCo marketing manager
I want customers to register their e-mail addresses
So that we increase the sales of our print consumables

And changing it to this:


In order to increase the number of sales of our print consumables
As a marketing manager
I want customers to register their e-mail addresses

The intent behind this shuffling around is to get people to think about the problem in order of business value first, then the stakeholder then what the stakeholder thinks will deliver the value.

But, the story is talking about a stakeholder… In my experience, this doesn’t get the best value from the user story approach.

Stakeholder ‘stories’ or User Stories?

I’ve found that user stories are most useful when communicating to the team if they encourage a conversation around who the user is, what capability the user needs and why it’s important to the user (could that be why they are called “user stories”?). This helps us to understand what user experience they need and what capability will make that possible.

This template, brought to us by Rachel Davies and Tim McKinnon’s 2001 XP Day session “Tuning XP”, helps us with that:


As <some role>
I want <some capability>
So that <some benefit>

If we discuss this solely from the business stakeholder’s point of view, the team doesn’t get as much understanding from what is needed by the user or why the user will need this capability. If the capability summarises what the product will enable or do for user it’s a lot easier to see what needs to be changed in the product. The benefit should be the answer to “what’s in it for the user?” or “why would they want the product to do that?” (exploring the persona of the user is helpful in finding this out).

So, taking the earlier PrintCo example, an alternative way of writing the user story would be like this:


As a PrintCo Customer
I want to be prompted to share my e-mail address with PrintCo
So that I can avoid those times when I need to print something but the ink is empty

Ah… but now we’re back where we started – where’s the business value? How do we get people to think about the business value first and then identify the roles and capabilities?

Let’s start again

Ideally, we want the benefit of driving the features from the business value and the increased understanding of what we’re implementing by understanding the user in our conversations around a user story.

 

To get to the right place, we need to start again with our example. Imagine that, instead of the above, we’d taken a different approach.

Recall that the business value or goal was:

Increase PrintCo printer cartridge sales by increasing our customer mailing list

Then, we could consider what behaviour we want to encourage and for whom. For example, we want the Customer to share their e-mail address with us online.

So, what will encourage that behaviour… What’s in it for our users? Into our business value statement, we “inject” the beginnings of a capability (or feature) that will help us deliver the value:


In order that PrintCo printer cartridge sales go up by growing the mailing list:
As a PrintCo Customer
I want <something>
So that an e-mail reminder helps me to avoid those times when I need to print something but the ink is empty

Now we’re ready to talk about the special <something> that we don’t currently have that will give the user the benefit they want:


In order that PrintCo printer cartridge sales go up by growing the mailing list:
As a PrintCo Customer
I want to be prompted for my e-mail address
So that an e-mail reminder can help me avoid those times when I need to print something but the ink is empty

We also want the Customer Services Rep to be encouraged to ask customers for their e-mail address when dealing with customers over the phone. So, we inject some more features:

In order that PrintCo printer cartridge sales go up by growing the mailing list:
  As a PrintCo Customer
  I want to be prompted for my e-mail address
  So that an e-mail reminder can help me avoid those times when
    I need to print something but the ink is empty

  As a PrintCo Customer Services Rep
  I need <something>
  So that I increase the points I get for e-mail captures, improving my
    position on the high-scores display

  As a PrintCo Customer Services Rep
  I need <something>
  So that I can see that the points I earn for e-mail captures affect my
    position on the high-scores display

And now we want to know what that special something is going to be for our Customer Services Rep:

In order that PrintCo printer cartridge sales go up by growing the mailing list:
  As a PrintCo Customer
  I want to be prompted for my e-mail address
  So that an e-mail reminder can help me avoid those times when I need
    to print something but the ink is empty

  As a PrintCo Customer Services Rep
  I need to be prompted to ask for the customer’s e-mail address
  So that I increase the points I get for e-mail captures, improving my
    position on the high-scores display

  As a PrintCo Customer Services Rep
  I need e-mail captures shown as one of the columns on the high-scores display
  So that I can see that the points I earn for e-mail captures affect my
    position on the high-scores display

And, if it is important that you capture the key stakeholder:


In order that the Marketing Manager grows PrintCo printer cartridge sales by growing the mailing list…

Or, you don’t need to even use ‘In order to’… you can word it any way you like


Goal: the Marketing Manager wants to grow PrintCo printer cartridge sales by growing the mailing list…

The most important thing here is not the wording. It’ that we find a way of keeping the business value in the conversation and when we’re talking about the capabilities, we focus on the user. What I’ve described is just one way of achieving that.

It’s like a “theme” for the stories

Themes have been suggested by many as a way of grouping user stories. In this case, the ‘In order to…’ can be thought of as a theme for the stories – i.e. the theme is described in terms of business value. Stories, described in terms of the user capability and incentive/context, are injected into the “theme” as we identify roles and capabilities that deliver the business value.

Notice, that I thought about the “As a…” and “So that…” aspects of the user story first and then summarised the capability, yet the order in which I expressed them remained as normal. As Rachel Davies once highlighted to me, just because we think of these things in one order, that may not be the best order for a discussion with the people who will implement it.

Another way of putting this is that the “As a… I want… So that…” is optimised for the conversation that helps the product owner(s) communicate what is required to the rest of the team, not for the order in which we generally discover the information.

In Summary

As you can see, Feature Injection doesn’t encourage you to simply move the “So that” to the beginning and reword it with “In order to”. I can see why people do that. One possible reason is because the stakeholder intent has been mashed into a user story, but that loses the purpose of a user story. I can also see why that happens, because there wasn’t an obvious place to think or talk about stakeholder intent. Business-value focused themes give us that.

I hope this helps clarify a little about Feature Injection and how it relates to user stories… but remember, this is only the tip of the Feature Injection iceberg. Actually it’s just one of the outcomes of Feature Injection. Watch this space for more.

Putting Cucumber where it’s not supposed to go will hurt!

Today, I came across this post by Ryan Bigg where he talks of the pains he’s experienced with Cucumber.

Fortunately for Ryan, the outcome was a positive one, he ended up finding what appears to be a nice looking API for automating test-execution.

The experience he had with Cucumber, however, is a common one. Often teams start using Cucumber in an effort to reduce the need for programming skills when writing automated tests.

This isn’t the problem that Cucumber and other BDD tools are trying to solve and this is why so many teams who misuse it in this way experience difficulty and frustration.

BDD tools like Cucumber are designed to help teams and their customers arrive at a shared understanding of the problem they wish to solve (in terms of the user’s goals and tasks). It’s not really intended to describe the solution (i.e. step-by-step interactions with the GUI).

If your Cucumber scenarios have words such as “click” or “type” or mention field names and the like, it’s probable that you’re either:
a) Using Cucumber to automate test-execution (not what it was intended for) or
b) Trying to do BDD but writing the scenarios at too low a level of detail.

If you’re doing the latter (b)… then you may find the post I wrote over the weekend useful.

If what you’re doing is (a) then the post I wrote over the weekend might help you go down a path where automating your tests will make the transition to BDD that much easier.

If you really, really only want to automate test-execution then you might find that you’re putting Cucumber where it’s not supposed to go… and just so you know – that’s probably going to hurt :-)

A bit of UCD for BDD & ATDD: Goals -> Tasks -> Actions

There’s something wrong with many behaviour specs (or acceptance tests). It’s been this way for some time. I’ve written about this once or twice before, referencing this post by Kevin Lawrence from 2007.

So, first things first, I want to take this opportunity to update the terminology I use…

Goals -> Tasks -> Actions
A useful technique used in User-Centred Design (UCD) and Human Computer Interface (HCI) design is Task Analysis. There are three layers of detail often talked about in Task Analysis:

Goal: What we’re trying to achieve which has one or more…
Tasks: The high-level work-item that we complete to fulfil the goal, each having one or more…
Actions: The specific steps or interactions we execute to complete the task.

Previously, the terms used by Kevin, myself (and several others) were Goal->Activities->Tasks. From now on, I’m going to use the UCD/HCI/Task Analysis terms Goal->Task->Action. It’s exactly the same model – just with different labels at the three layers of detail.

What’s wrong with your average behaviour spec?
Let’s look at a common example… The calculator. For convenience, I’m going to borrow this one from the cucumber website[1].

Scenario: Add two numbers
Given I have entered 10 into the calculator
And I have entered 5 into the calculator
When I press add
Then the result should be 15 on the screen

[1]note: I’m using this example for convenience and simplicity. The value of the example on the cucumber website is to demonstrate how easy cucumber is to use and not necessarily as an exemplar feature spec

What would you say the scenario’s name and steps are representing? Goals and Tasks or Tasks and Actions?

I’d argue that adding two numbers is a task and the steps shown above are actions.

Instead, I try to write the spec (or test) with a scenario-specific goal and the steps as tasks.

Scenario: sum of two numbers
When I add 10 and 5
Then I should see the answer 15

I.e.:
Scenario: <A scenario specific goal>
Given <Something that needs to have happened or be true>
When <Some task I must do>
Then <Some way I know I've achieved my goal>

Another Typical Example
Let’s apply this to another typical example that might be closer to what some people are used to seeing:

Scenario: Search for the cucumber homepage
Given I am at http://google.com
When I enter "cucumber" into the search field
and click "Search"
Then the top result should say "Cucumber - Making BDD fun"

Again this is talking in terms of actions. As soon as I’m talking in terms of click, enter, type or other user-action, I know I’m going into too much detail. Instead, I write this:

Scenario: Find the Cucumber home page
When I search for "Cucumber"
Then the top result should say "Cucumber - Making BDD fun"

Why does it matter?
In the calculator example, the outcome the business is interested in for the first scenario is that we get the correct sum of two numbers. The steps in the scenario should help us arrive at a shared understanding of what ‘correct’ means. How we solve the problem of getting the numbers into the calculator and choosing the operator is a separate issue. That’s detail we can defer. It may be better to explore the specifics of the workflow using, sketches, conversation, wire-frames or by seeing and using our new calculator.

So, expressing our scenarios in terms of goals and tasks helps the delivery team and the business arrive at a shared understanding of the problem we’re trying to solve in that scenario.

Expressing the scenario in terms of the clicks, presses and even fields we’re typing into is focusing on a solution, not the problem we’re trying to solve.

But there’s another benefit to doing it this way…

A Practical Concern – Maintainability
The first calculator example follows reverse-polish notation for the sequence of actions:

  1. enter the first number
  2. enter the second number
  3. press add

If we put that detail in the scenarios, that workflow will be repeated everywhere – for addition, subtraction, division, multiplication… and anywhere any calculation is described.

What happens if the workflow for this calculator (such as the UI or API) changes from a reverse-polish notation to a more conventional workflow for a calculator? Like this:

  1. enter the first number
  2. press add
  3. enter the second number
  4. press equals

The correct answer hasn’t changed – i.e. the ‘business rule’ is the same – it’s just the sequence of actions has changed.

Now we have to go through all the feature files and update all the scenarios. In the case of our calculator that may only be a few files covering add, subtract, divide, multiply. For something larger and more complex this could be a lot of work.

Instead, putting this in the code of the step-definition means that this:

When ^I (add|subtract|divide|multiply) (.*) (?:and|from|by)? (.*) do |operator, first_number, second_number|
@calc = @calc ||= Calculator.new
@calc.enter first_number
@calc.enter second_number
@calc.send operator.to_sym
end

Would have to change to this:

When ^I (add|subtract|divide|multiply) (.*) (?:and|from|by)? (.*) do |operator, first_number, second_number|
@calc = @calc ||= Calculator.new
@calc.enter first_number
@calc.send operator.to_sym #moved up from the bottom
@calc.enter second_number
@calc.calculate #new action for the conventional calculator workflow
end

Nothing else would need to change – other than the product of course. By writing the steps as tasks, all of our feature files would still accurately illustrate the business rule even though the workflow of the interface (gui or api) has changed.

Taking your scenario-steps to task
So, taking this approach helps us to reduce our maintenance overheads. Putting the Actions inside the step definition makes our tests less brittle. When the workflow changes we only need to update our specs in one place – the step-definitions.

Of, perhaps, greater importance – by capturing the user’s scenario-specific goal as the scenario name and the tasks as the steps, the team are working towards a shared understanding of the part of the problem we’re trying to solve not a solution we might be prematurely settling upon. When rolled up with the broader context (expressed in the user-story and its other scenarios) it gives us a focus on solving the wider problem rather than biasing the solution.

Sometimes, at first, it’s hard to see how to express the scenario and is easier when people start by talking of clicks, presses and what they’re entering. And that’s ok. Maybe that’s where the team needs to start the conversation. Just because that’s where you start, ask “why are we doing those actions” a few times, and it doesn’t have to be where you end up.