« Table of Contents »
Previous Chapter « Effective Behaviour Specification Steps

The Behaviour Specification Handbook

The Implementation Process

This final chapter in The Behaviour Specification Handbook provides various tips for implementing Behaviour Specifications.

1. Behaviour Specifications Before Implementation
2. The Roles Of Developers and Test Analysts
3. Identify Which Developers Will Code Each Behaviour
4. Identify Who Will Code The Automation Or Manually Perform Each Test
5. Code!
6. Separate Implementation Of Unit Test Steps From Integration Test Steps
7. Review Test Outputs

Next » Behaviours Before Implementation

« Table of Contents »
Previous « Behaviour Specifications Before Implementation

The Behaviour Specification Handbook

The Implementation Process

The Roles Of Developers And Test Analysts

During development of a software component, the developers should implement, as automated tests, all the tests that the team has agreed to be Unit Tests. Depending on the team, the developers ideally also would implement the Integration Tests as automated tests. However, team composition and other delivery practicalities can dictate otherwise, and perhaps there might be other test automation engineers available to implement the automated Integration Tests.

Regardless of whether the developers implement both the Unit and Integration Tests as automated tests, test analysts still play a vital role in team. Below is a list of some of the important activities that test analysts perform.

• Behaviour Specification writing – during the Behaviour Specification writing sessions, the test analysts provide their unique, test-focused perspective, which helps the team to ensure that all the positive and negative behaviours have been identified;
• Test analysis — determining the types and structure of the test data that will be required and helping the developers understand that for mocking data in Unit Tests, or for dynamically setting up and tearing down test data as part of automated Integration Tests;
• Reviewing test output — as each developer finishes implementing an automated test, a test analyst should sit down with the developer and peer review the test output. During this review, the test analyst is ensuring that they understand the output and can agree that the test has been performed just as if they would have performed it. Thus the test analyst can, with their hand on their heart, record in the Test Management tool that the Behaviour Specification is complete;
• Verifying that the automated tests are actually doing what they are supposed to do in a specific environment, by picking a couple of automated Integration Tests on an adhoc basis, performing them manually and comparing the output of the automated test with the results of the manual execution. This type of adhoc manual testing can, for instance, highlight issues where some of the configuration of the automated tests might be incorrectly pointing to a wrong environment;
• Setting up test data for manual Integration Tests or manual End-to-End Tests;
• Performing manual Integration Tests — depending on the situation, there could be quite a few Behaviour Specifications that the team has tagged to be tested manually;
• Performing manual End-to-End Tests;
• Performing higher-value, adhoc, exploratory testing;
• Performing test management activities;
• Gently assisting developers to remain focused and on-track; and
• Performing analysis in preparation for the next sprint.

As you can see, there is plenty of work for everyone in the team!

Next » Identify Which Developers Will Code Each Behaviour

« Table of Contents »
Previous « Overview Of The Gherkin Language

The Behaviour Specification Handbook

Behaviour Specifications

Thoughts On Gauge

The relatively new kid on the street is Gauge. Gauge is an alternative and similar way of specifying behaviours, but it does not follow the Gherkin syntax. In Gauge, behaviours are defined in “Specification” files that follow the Markdown syntax. Each Behaviour Specification is described with a heading and description, and then is defined further as a series of executable steps.

The main difference between the syntaxes used in Gauge and Gherkin is that there is no specific syntax in Gauge that must be followed to define each step. In Gauge, each step can be written completely in free-text. There is no “Given”, “When”, “Then” restrictive syntax like in Gherkin, and this flexibility can be a powerful drawcard for some people.

However when used in real life within the context of a business, this flexibility and power can be counter-productive. In a business, teams need to act responsibly and in a cost effective manner — which means teams should have agreed standards that are consistently followed. Consistency in language, communication patterns and style is important in a business in order to minimise the overall costs of development, maintenance and staff training. If a business decided to use Gauge as their Behaviour Specification and execution tool of choice, the first thing the business should do, in order to keep costs to a minimum, is to create a standard style guide to promote consistency. An effective standard more than likely will significantly restrict the syntax of the steps — so the drawcard of free-text becomes a moot point. In the end, you may as well have just used Gherkin. The Gherkin syntax “ain’t broke” and is quite effective — although as you will see later, I recommend an even more restricted style!

Sure, there are many cross-language features in the Gauge tooling that may pique your interest, and if you need that functionality then go for it — but please don’t base your decision on the flexibility of free-text steps!

I have found that the Gherkin syntax is an excellent foundational structure, and I will continue to recommend it. Since the Gauge syntax is unrestricted, the recommendations presented here can be applied easily within Gauge specifications as well.

Next » Feature Files

« Table of Contents »
Previous « Reuse Steps, If Possible

The Behaviour Specification Handbook

Effective Behaviour Specification Steps

Understand Technical Tool Constraints

At the end of the day, the developers and/or testers must be able to successfully implement the Behaviour Specifications as automated tests. If they cannot do so because of reasons related to the technical tool that enables the execution of the Behaviour Specifications (e.g. Cucumber, SpecFlow, etcetera), then either the style of writing the Behaviour Specifications must be altered or the tool must be changed.

There is a constraint with the tool Cucumber that may prevent a team from following some of the recommendations in this handbook. With Cucumber, each step within a set of feature files that are executed together is unique and only can have one corresponding implementation. Because of this, when using Cucumber, there cannot be Behaviour Specification steps with the exact same wording in more than one feature file, and with different implementations that are specific to the context of their software component. For example, it would not be possible to implement the suggested approach of having different feature files for the different User Interface mechanisms of voice or touch. With Cucumber, in order to make the wording of each step unique, there would be no choice but to embed specific technical implementation details into the wording of each step, so that each step can be precisely implemented as necessary. The other alternative would be to execute the feature files separately — but for the example of voice and touch interfaces, that does not seem like a good approach since they all relate to the same logical grouping of functionality.

This constraint is an intentional design decision made by the Cucumber development team, with the idea that it forces the usage of a ubiquitous language and fosters better reusability and clarity of steps. Here is one discussion about it, in case you are interested. However, defining more precise steps (in most cases, by specifying implementation details) with the goal that it increases pressure to grow a business’s ubiquitous language (more than likely with technical terminology) is not, in my opinion, a desirable goal or outcome.

The approach I recommend both embraces and highlights the context of a software component and feature file as the key to understanding each behaviour, and also strongly emphasises the usage of an accepted everyday business language. This also probably is another reason that many common behaviour examples follow practices that I do not recommend, because the idea of context is either not well understood or not embraced.

The Cucumber Backgrounder interestingly goes so far as to say that relating the step definition files to specific feature files is considered an anti-pattern – although quickly and wisely advises that you may depart from that advice when you are experienced enough to evaluate the trade-offs. Over the years I have given this a great amount of thought, attention and real-life practise, and with the guidelines in this handbook, I have witnessed many more benefits than negatives. Unfortunately, Cucumber does not appear to be the right tool for the job. There are however other suitable tools available.

In the world of Ruby, Turnip partly was created because of a desire to have step implementations scoped to behaviours.

In the .NET world, the open source tool SpecFlow provides the test automation developer with the option of reusing existing step implementations where useful and desired, and also the ability to have different implementations for the same step wording in different feature files. This choice is made in the implementation code via SpecFlow’s “scope” mechanism, based on criteria such as the title of the feature or “@tags” that are specified at the top of the feature file or on each individual Behaviour Specification.

I strongly recommend the usage of a tool like SpecFlow because of this enabling capability that allows experienced people to make their own choice, without being forced to push a square peg into a round hole. Having said that, many kudos must go to the Cucumber team for their continued effort and dedication over the years, and the community they have inspired.

Next » Single When

« Table of Contents »
Previous « Indicate Primary or Secondary Behaviour

The Behaviour Specification Handbook

Effective Behaviour Specification Descriptions

Unique Within Their Feature File

Helpful, intention-revealing Behaviour Specification Descriptions can become a little verbose. As such, it can be very useful for team members to have a mechanism to easily identify or refer to a specific Behaviour Specification from the long list of specifications in the same feature file.

In my experience, it is beneficial for each Behaviour Specification Description to have a numeric-based identifier that is unique within the scope of the feature file. This helps team members to quickly find or reference specific specifications in that feature file.

It also is better if the numeric-based identifier is not a consecutive, sequential number. By intentionally leaving gaps between the numbers, new Behaviour Specifications easily can be inserted in between the existing behaviours, without causing people to have the desire to do any time-wasting renumbering.

In addition it is benficial to prefix the numeric-based identifer with an acronym that represents the type of test - such as UT for a Unit Test or IT for an Integration Test. This is in addition to the @tag above the scenario description.

It also can be helpful and meaningful to logically group a specific positive behaviour with its related negative behaviours. All the related behaviours can be given the same numeric identifer, and then be suffixed with a different letter of the alphabet to make them each unique. See further below for an example.

Next » Unique Without Their Feature File

« Table of Contents »
Previous « Unique Within Their Feature File

The Behaviour Specification Handbook

Effective Behaviour Specification Descriptions

Unique Without Their Feature File

Test analysts in particular like to reference test cases and copy the Behaviour Specification Descriptions into test management tools, defect records and reports. Other team members also like to refer to specific Behaviour Specification Descriptions in Application Lifecycle Management (ALM) tools and other documentation. When there are many behaviours living in different feature files, how does one easily and unambiguously reference them?

A simple way to enable team members to uniquely identify, refer to and find the behaviours that may be scattered across different components or feature files is to ensure that each Behaviour Specification Description includes a unique identifier for the software component or feature file. I recommend prefixing each Behaviour Specification Description with the feature title/name (or a shortened and still unique version of the feature name) to ensure that when a team member uses the behaviour description outside of the context of the feature file, there is no question about where it originated from or where it should be found.

Next » Follow This Template

« Table of Contents »
Previous « Write One Specification For One Behaviour

The Behaviour Specification Handbook

General Tips

Use Present Tense

Behaviour Specification Descriptions and steps tend to make more logical sense when written in the present tense, because they are describing the most up-to-date, current, at the present time, expected behaviour. If a description or step is written in the past or future tense, then it does not represent the current, as-built, living documentation of the component.

Next » Avoid Generic Verbs

« Table of Contents »
Previous « Behaviour Specifications

The Behaviour Specification Handbook

Behaviour Specifications

What Are Behaviour Specifications?

Behaviour Specifications conveniently and efficiently fulfil multiple purposes:

1. Written in everyday business language, they comprehensively and unambiguously specify the required functionality to be delivered, as agreed by the team;
2. They are the specifications that developers should refer to when they write code. The only code that should be written by a developer is code to satisfy the Behaviour Specifications. Remember this little motto: “No Behaviour Specification? No Code! No Test!";
3. They also represent the complete set of test cases that are needed for the given functionality;
4. They are the living, up-to-date, as-built documentation, for the entire team (and potentially other parts of the business), about the functionality of each software component; and
5. When implemented as automated tests, they are the executable documentation that becomes part of a suite of test assets.

Behaviour Specifications are NOT part of a formal requirements document or legal contract — they are as-built documentation and test assets. As discussed in Prerequisites, requirements are a prerequisite input for the process of specifying behaviours.

Next » No Other Test Cases Are Necessary!

« Table of Contents »
Previous « Feature Names

The Behaviour Specification Handbook

Behaviour Specifications

What Is A Behaviour Specification Description?

A Behaviour Specification Description (also known in Gherkin as a “Scenario” description) is a one-line, simple, precise summary of an expected behaviour of a software component. I recommend the description be worded in commonly accepted, everyday business language, without specifying internal technical implementation details. Each description must be sufficiently precise so that all the Behaviour Specifications of a given software component can be clearly differentiated.

Example Behaviour Specification Descriptions

As an example, say that there is a User Interface component that invokes a back-end service to perform validation of a postal address. The Behaviour Specification Descriptions of this User Interface component could include:

• Positive - Should allow a specified postal address to be submitted for validation;
• Positive - Should transform the submitted address data into a format that is required by the address validation service;
• Positive - Should invoke the address validation service with the appropriately formatted address data;
• Negative - Should provide a notification of a technical error when there is an issue communicating with the address validation service;
• Positive - Should provide a notification of an invalid postal address when the address validation service determines the address is invalid; and
• Positive - Should provide a notification of a valid postal address when the address validation service determines the address is valid.

The behaviours of this User Interface component explicitly do NOT include anything related to how the back-end service performs the validation. Those types of concerns are only the service’s behaviours and are not the concern of this User Interface component.

Please make a note of these example Behaviour Specification Descriptions, as they will be referred to in some of the following sections.

Next Chapter » The Behaviour Specification Writing Process

« Table of Contents »
Previous « Scaling To Large Solutions

The Behaviour Specification Handbook

Background

What Is A Software Component?

A software component is a logical grouping of functionality that is represented as an application, sub-system, service, micro-service, library, module, or any sort of implementation of part of an architectural layer. The granularity and boundaries between software components really depends on what makes logical sense. As a general guideline, a software component typically is larger than one class or module — although this guideline may not apply in the case of micro-services.

For example, a software component could be the functionality that provides the User Interface for a screen, or it could be the functionality of a back-end service operation. A software component also could be a specific part of a data access layer or repository.

Teams should carefully consider the design of their software components, as these choices affect later stages of the software development lifecycle. If a team ever struggles with maintaining a well structured Testing Pyramid, consider reviewing the boundaries of the software components. Splitting a large component into many, each with less responsibilities, could open the door to simplified Behaviour Specifications, a better Testing Pyramid, easier comprehension of functionality, and a lower total cost of ownership.

Next Chapter » Behaviour Specifications