The curious lifecycle of behaviour driven development scenarios

Behaviour Driven Development offers some unique benefits compared to document artefacts found in more traditional software development projects. One of the more useful benefits is that it’s a shared document that lives, and provides value, throughout the life cycle of a software project.

Consider a long lived document like the one hinted at above, compared to a Business Requirements Specification, plus a Functional Specification, plus a Technical Specification, and then ultimately, a Test Suite which all essentially hand off from one to the other. A wholly unwanted side-effect of this is a broken telephone effect, where definite and non-negligible loss in the fidelity of requirements naturally unfolds. BDD essentially eliminates the need for these different documents, and offers a simpler way to collaborate and maintain requirements knowledge over a project’s lifetime.

This article aims to outline some of our experience in what happens when building out cucumber specifications with clients, and how to spot and remedy some of the pitfalls that may occur.

The egg stage

This stage of the development process is filled with promise. The whole team envisions all the possibilities that could emerge from this tiny seed.

For this phase, analysts should work primarily with business stakeholders (although it’s encouraged that developers and testers are present too) to gather high level features, and turn as many of those features as feasible into User Stories, or preferably Job Stories. This serves as the basis for why a feature, as we like to say, deserves to live.

What you’ll typically find during this phase is that scenarios built here will be of the declarative ilk. A common phenomenon here will be that they might be too declarative to the point of being nearly unusable. This is absolutely fine and normal. To counteract this, it is extremely important that the essence feature story is rock-solid. Feel free to mitigate some of the vagueness by putting some rough wireframes together.

    Feature: Place an order for new shoes.
        When I've found the perfect pair of shoes and it's a few days until the party
        I want to pay for them and ship them with priority
        So I can get them in time and not have to wear my old pair.

        Scenario: Pay for shoes
            Given I have found my pair of shoes
              And I have entered my credit card details
             When I click 'Buy'
             Then I should have a payment receipt in my inbox.

The caterpillar stage

We’re now at the point where we have something to work with, it may be a little hairy, a little unwieldy, and none too graceful, but it’s a start, and the promise of something great can be seen.

Once the developers have enough to go on (what this exactly is serves as the basis for a whole other post), they can start developing based off a prioritised list of features and scenarios within those features. Developers will typically tweak the scenarios to be more inline with some of their scenario parsing tools, and this may mean an inching towards a more imperative style of scenario. Manage these changes via collaborative channels.

Once developers start closing off features according to the scenarios outlining behaviour, it’s crucial that two things happen.

1) The analyst in charge ensures that features and scenarios are up to date, and there are more waiting for developers. 2) Testers get at the software that’s ready for testing.

    Feature: Place an order for new shoes.
        When I've found the perfect pair of shoes and it's a few days until the party
        I want to pay for them and ship them with priority
        So I can get them in time and not have to wear my old pair.

        Background:
            Given I am logged in
              And my credit card details are saved to my account

        Scenario: Pay for shoes
            Given I have added 'Nike MAGs' to my basket
              And I have selected 'Expedited Shipping'
             When I click 'Buy'
             Then I should see a successful transaction message with a receipt number

The pupa stage

At this point in a scenario’s lifecycle, things start to settle down and take real shape. Final forms are fleshed out, and by now we will have a real inkling of what lies ahead.

Any good tester worth their salt should actually be called a quality engineer. They’ll look past the features and consider other aspects like user experience, usability, speed, load testing and security. BDD doesn’t attempt to replace any of these toolsets, so make sure they’re still covered.

Where a tester can add to the BDD cycle is by adding boundary testing, and fuzz testing to the suite. Whether or not this is kept in separate feature files to keep the so-called happy path clear, or whether an imperative or declarative style is used is entirely up to the convention of the delivery team. The only recommendation is that consistency is applied.

It’s important to state is these features and scenarios are used manually (i.e they haven’t been wired up to automation code yet), stay as imperative as you can.

    Feature: Place an order for new shoes.
        When I've found the perfect pair of shoes and it's a few days until the party
        I want to pay for them and ship them with priority
        So I can get them in time and not have to wear my old pair.

        Background:
            Given I am logged in
              And my credit card details are saved to my account

        Scenario: Pay for shoes
            Given I have added 'Nike MAGs' to my basket
              And I have selected 'Expedited Shipping'
             When I click 'Buy'
             Then I should see a successful transaction message with a receipt number

         Scenario:Item is out of stock
             Given I have added 'Glass Slippers' to my basket
              When I click 'Buy'
              Then I should see an out of stock message

The imago stage

By now, we should have a full set of features and scenarios that map 1:1 to delivered software. In order to keep our beautiful software alive, it’s important that it continues to undergo micro-lifecycles within it’s project. When a feature changes, is removed, or replaced, follow the same process and make sure everyone involved in the delivery is still included and collaborated with.

    Feature: Place an expedited order for new shoes.
        When I've found the perfect pair of shoes and it's a few days until the party
        I want to pay for them and ship them with priority
        So I can get them in time and not have to wear my old pair.

        Background:
            Given I am logged in
              And my credit card details are saved to my account
              And my default shipping preference is 'Expedited'

        Scenario: Pay for shoes
            Given I have added 'Nike MAGs' to my basket
             When I click 'Buy'
             Then I should see a successful transaction message with order and tracking numbers

Some BDD nuggets

• Automate your test suite at the earliest opportunity, and get that automation into your CI platform.
• Analysts need to walk a fine line between declarative and imperative features. When in doubt, ask yourself, “Would the stakeholder find these features too detailed?”. If yes, and they must be imperative, put them in a feature file marked as not important for stakeholders, or at the very least, a separate section in a feature file clearly marked for testing only.
• BDD features and scenarios are not a proxy for face-to-face collaboration.
• Expect the BDD process to spark conversations about the software. Be ready to act on the feedback from those conversations.
• Testers and analysts will need to have a basic understanding of the development teams revision control process in order to add to the content of scenarios and, as a bonus, should be able to spin up their own development environment to play with pre-prod versions of the software. There are plenty of GUI apps, and Devops toolsets to make this easier.

Hey Developer! Up your time management game

To me, the most amazing feeling in the world is, when I create something, out of nothing, by using code. I feel utterly rewarded and fulfilled when I’ve been struggling with a problem, and finally that light dawns upon me after hours of hard work and discipline. I admit, after entering the development world, I’ve derived a new-found appreciation for every piece of work out there on the internet, because now I know that someone has used all their blood and sweat behind the scenes, and it’s not all just ‘magic’.

With all the joy that comes from programming, there is bound to be some side-effects. Some of these known side effects are:

• extreme hair pulling (now you know the secret of the developer beard),
• mood-swings depending on how well your code for the day is going (caution: this could result in your spouse making you sleep on the couch for the night),
• feeling overwhelmed (yet, so very satisfied once you’ve realised that you’ve totally rocked that code),
• and the list goes on..

Being a developer has made me realise that my day can be like a roller coaster if I do not ensure structure.The number one change you can introduce to bring some order to that chaos is time management. Time management is extremely essential to ensuring productivity. Hence, I’d like to share some techniques that I use as often as possible to assist in making me more effective.

The Pomodoro technique is the secret weapon that gives structure to my day. I basically use a timer to break down work into intervals that are traditionally 25 minutes in length, separated by short breaks. The idea is that short periods of time yield higher focus and small, frequent breaks can improve mental agility.

There are 5 basic steps in the process:

• Decide on the task to be done
• Set the pomodoro timer to 25 minutes
• Work on the task until the timer rings
• Take a short break for 3–5 minutes.
• After four pomodori, take a longer break of 15–30 minutes. (Yes, we looked it up, the plural of pomodoro is pomodori)

The Pomodoro technique keeps me aware of the time passing, and assists in minimizing distractions that could lead me into non-productive Yak-shaving sessions. Personal time-boxing is said to help curb perfectionist tendencies until the appropriate time. It allows me as a developer to concentrate on the task at hand and steadily work towards an end goal. An app that I recommend using is Eggscellent. It is a visual, integrated and customisable tool that works beautifully.

In conclusion, time is not a fungible resource and unless managed correctly, can lead to a dissatisfaction in all aspects of ones life. The Pomodoro technique is mainly known for its ability in helping one keep focused and providing a systematic way to tackle daily tasks. For me, this technique was, and continues to be, a life-changer.

Safely storing passwords and secrets in your git repo

Managing secrets for a code base is a tricky proposition. For too long, traditional DevOps approaches have seen teams build elaborate out-of-band workflows to manage system secrets, API keys and tokens, and traditional passwords. This tends to be an error-prone and painful process. This is never a good scenario to be faced with when considering options around security.

At the same time, storing these secrets inside your DVCS is also a really easy way to get onto the MyBroadband or IT Web front page with a “YourCompany: HACKED!” headline.

As an illustration, a quick GitRob spree on your local GitHub organisation can reveal some serious vulnerabilities that are literally just waiting there for someone to exploit. I ran this on an open source project whose name I will not disclose, and got some very interesting results that could lead to a lot of mischief.

Recently, some new software has hit the scene: BlackBox, a utility built by the smart people at StackExchange. Blackbox is a suite of scripts that aims to marry the ever-warring security and convenience into something that should satisfy both the development and security teams.

Blackbox uses GPG to encrypt files before they’re sent to your DVCS (assuming GitHub for the remainder of this article), and decrypts them when needed, either by you, your team, or an automated system. Blackbox is so promising, that in fact ThoughtWorks have identified it on their tools to assess for the January 2015 Tech Radar

There really is a lot to cover in terms of workflow, but for today we’ll keep it simple, and walk through the most typical steps of starting a blackboxed project, adding files, editing files, and adding collaborators.

Dependencies

The following instructions assume some basic groundwork has been laid down.

• You are working on a project hosted on GitHub or similar online source code management tool.
• You and your whole team have access to this project
• As all examples are run from the shell, you are comfortable running shell commands
  • If you’re copying and pasting the commands below from ZSH instead of BASH, please run this command first setopt interactivecomments
• You have blackbox installed as per one of these installation methods.
• You have GPG installed
• You have GPG keys on your machine (Zero One uses, and loves Keybase.io)
  • Use Keybase and install your keys via keybase login, or
  • Simply generate your own keys via the GPG command line. You can use this tutorial to get started

Prep your project for Blackbox

Start up your gpg-agent so your passphrased keys are stored in memory:

$ eval $(gpg-agent --daemon)

Let Blackbox initialize some housekeeping files:

$ blackbox_initialize

The next command is provided by blackbox, just copy and paste your version:

$ git commit -m'INITIALIZE BLACKBOX' keyrings .gitignore

Now add yourself as an admin

Blackbox requires admins to be managed via a simple text list file, and a keyring of GPG keys. The keyring is used so that all admins can have their own keys, and still decrypt files. As we’ve said earlier, we’re fans of Keybase, a crypto service that helps manage GPG transmissions. I’ll be encrypting files using my Keybase ID.

To see a list of GPG keys on your machine, and to get the UID you need to provide blackbox with, run:

$ gpg --list-keys

Choose your key, and give the UID to blackbox:

$ blackbox_addadmin keybase.io/gee_forr

Time to get some files blackboxed

Let’s get Blackbox to manage a couple of secretive files for us. To do this, we register a new file with a simple command. In this demo, I’ll be encrypting a Rails app’s secrets.yml and database.yml files. You can add as many, or as few files as you wish. Really paranoid people might want to consider even blackboxing the db/schema.rb file.

$ blackbox_register_new_file config/secrets.yml
$ blackbox_register_new_file config/database.yml
$ blackbox_register_new_file db/schema.rb

Blackbox does a couple of clever things here. Firstly, it adds the GPG version of the file to the git repo, and secondly, it adds the unencrypted file’s name to the repo’s .gitignore file so that you won’t accidentally add the decrypted file back into source control.

What about editing blackboxed files?

To edit a file, you have a number of options. You can decrypt, then edit, then encrypt, or you can do that all in one command.

$ blackbox_edit config/secrets.yml.gpg

This will prompt for your passphrase, decrypt the file, and open up $EDITOR. Writing and quitting the editing session will re-encrypt the file.

Whilst you’re editing secrets.yml, why not remove the production reference to an env var, and put the secret key right in there? Don’t forget to keep on committing changes as you go along.

If you want to have a file decrypted so that you can run a development environment, just run blackbox_edit_start on the file name. This will decrypt it and do nothing else. Running blackbox_edit_end on the file name will re-encrypt.

I work on a team, how do I get other devs access to these files?

This is a slightly finicky process. It involves all the prerequisites outlined above, and then implements a “vouchsafe” process to allow new people onto the project. Here’s another reason we love Keybase. Keybase provides a way for someone to verify another person using their social media logins. If you know someone’s Twitter or GitHub handles, you can find their Keybase fingerprint from there, and rest assured that the person you are “indoctrinating” (Blackbox’s term, not ours) is who they claim to be.

On your new colleagues machine, the following commands are run from within the project’s repo:

$ blackbox_addadmin keybase.io/ridhwana

Here, Ridhwana adds her Keybase UID. This outputs a git command suggestion for committing the files.

Push the application for the new admin back to the central git repo:

$ git push

Once the application for admin rights is back on a central git repo, a current admin can continue the indoctrination process on their machine.

Fetch the latest code with the new proposed admin:

$ git pull

Add the new public keyring to GPG

$ gpg --import keyrings/live/pubring.gpg

Now decrypt and re-encrypt all the files using the new keyring:

$ blackbox_update_all_files

And finally push all these changes back to your central git repo

$ git commit -a
$ git push

From this point on, both admins should be able to work with these files securely.

Other points to consider

What happens when someone leaves the team?

Standard practice in these cases, with or without a tool like Blackbox, should be to regenerate any keys or tokens, and change any passwords. Once that’s done, running the blackbox_removeadmin command will help to remove their key from the keyring, and re-encrypt all files.

What about automated systems that need to access these files?

Your CI server, or orchestration servers can have a GPG key without a passphrase added. This is done by creating a sub-key from another key. These servers should be locked down extremely tight. If someone breaks into a server like this, you’ve already lost, and fretting over a machine-use-only key will be the least of your worries.

These machines kill mediocrity

Where we stand

Zero One is still a young company that’s finding its feet, and as a result, we’ve had to be flexible with some of our decisions and goals.

There’s one place where we aren’t willing to be flexible, nor are we open to negotiation. That place is our work ethic.

It’s too easy to cut a corner here, and make an unfulfilled promise there, and that attitude becomes a slippery slope we just aren’t prepared to get on. But first…

A very quick and super interesting history lesson

Woody Guthrie was a singer/songwriter predominantly active around the time of World War II. He was somewhat unique in that he was an early example of a celebrity that used his fame to political ends. Specifically in his case, he was extremely outspoken regarding the disturbing rise of totalitarianism in Germany and Italy pre-WWII.

One of the methods he employed to raise awareness was to mark his guitar with the words “This machine kills fascism”.

Back to the present

It’s 2015 however, and luckily fascism is largely absent from our daily lives. So, instead Zero One has set its sights on something it can fight against. Every day, we’re confronted with examples of poor design, minimum effort, complancency, and being rewarded for just showing up. We don’t think that’s good enough. We think that’s mediocre, and we think mediocrity needs to be killed.

We believe so strongly in the value of doing great work that we’ve decided to brand our tools accordingly. We hope you feel as strongly about this as we do, and grab a sticker for yourself the next time you bump into a Zero One developer.