« Table of Contents »
Previous « Effective Behaviour Specification Descriptions
The Behaviour Specification Handbook
Effective Behaviour Specification Descriptions
Start Behaviour Descriptions With “Should”
In order to write an effective Behaviour Specification Description, describe each behaviour in a sentence, beginning with the word “Should”.
The word “Should” at the beginning of a sentence helps to focus both the author and reader on the actual intent of the behaviour.
In the English language, behaviours generally are described with verbs.
The next set of words grammatically after “Should” typically is a verb or adverb.
By starting with “Should”, the structure of the English language is forcing the optimisation of the descriptions so that we can immediately focus on the intent of the actual behaviour and more quickly understand how it may differ from other behaviours.
A template format for the recommended wording of a Behaviour Specification Description is:
1 Should [action] when [criteria]
The first part of the description is the action to perform, and the second part is the criteria for the action to occur.
For example:
1 Should calculate the invoice amount when an order item is added to an order
This description is clear and intention-revealing about the behaviour. A reader immediately knows and understands that the behaviour is to “calculate the invoice amount”, and the criteria for this occurring is “when an order item is added to an order”.
Applying a standard such as beginning Behaviour Specification Descriptions with the word “Should” helps teams to write more useful and intention-revealing descriptions and naturally fall into the “pit of success”.
Different From A Test Case
A Behaviour Specification Description is subtly different from a description of a Test Case. A traditionally written description of a Test Case is authored from a different perspective that typically aims to summarise the scenario and steps that are taken.
For example, a contrasting traditional Test Case description for the example behaviour above would typically be:
1 Adding an order item
Hopefully you can appreciate the subtle differences between Behaviour Specification Descriptions and Test Case descriptions. The description of the Test Case is often shorter and at a higher summary level.
Behaviour Specifications Are Not Legal Requirements
As has been stated previously in this handbook, requirements are a prerequisite to the identification and writing of Behaviour Specifications.
The Internet Engineering Task Force (IETF) identifies an Internet Best Current Practice (BCP) of “Key words for use in Requests for Comments (RFCs) to Indicate Requirement Levels” - BCP 14 / RFC 2119. This document defines a number of key words as they are to be interpreted in IETF documents.
Of particular note is their definition of word “SHOULD”, meaning that:
"there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.“
I acknowledge that a pedantic reader of a Behaviour Specification Description could choose to interpret “Should do XYZ always” in English as “it should do XYZ always, BUT because you said the word ‘should’, it does not always have to… and therefore there is space for unintended behaviour”.
This same type of reader would suggest tightening the terminology in order to make it completely unambiguous and fit for a formally signed business or legal contract — by prefixing the description with the word “Must”, “Shall” or “Will” instead of “Should”.
Behaviour Specifications however, are not part of a formal business contract (such as a requirements document) that requires legally precise wording and change management.
Behaviour Specifications are only as-built, living documentation and test assets, and using the word “Should” is perfectly acceptable.
There is therefore no need to be concerned about the IETF definition and its irrelevance to Behaviour Specifications.
The Subtle Aspect of “Should”
In case you need any more convincing, Dan North, the originator of BDD, in Introducing BDD, eloquently adds more weight to the argument for using the word “Should”:
"A more subtle aspect of the word ‘should’ becomes apparent when compared with the more formal alternatives of ‘will’ or ‘shall’. ‘Should’ implicitly allows you to challenge the premise of the test: “Should it? Really?” This makes it easier to decide whether a test is failing due to a bug you have introduced or simply because your previous assumptions about the system’s behaviour are now incorrect.“