« Table of Contents »
Previous « Identify Which Developers Will Code Each Behaviour

The Behaviour Specification Handbook

The Implementation Process

Identify Who Will Code The Automation Or Manually Perform Each Test

At this point, the team has already decided which developers will code each behaviour, and now they need to decide who will code each automated test, or perform each manual test.

In the scenario where the developers are implementing the automated tests, I have found it can be beneficial for a pair of developers to work together in order to deliver a given software component. The first developer can be writing the code to implement the behaviour, and in parallel — or even beforehand — the second developer can be writing the automated testing code. This can allow each developer to focus on one type of technology and reduce the amount of mental task switching – thus streamlining each individual’s coding.

Next » Code!

« Table of Contents »
Previous « Start With Should

The Behaviour Specification Handbook

Effective Behaviour Specification Descriptions

Indicate Positive or Negative Behaviour

All good test suites include both positive and negative tests. Behaviour Specifications are the same in this regard.

Positive Testing should ensure that the functionality under test works as expected, produces expected errors as required, and does not produce unexpected errors.

Negative Testing should ensure that the functionality under test can gracefully handle an unexpected or invalid circumstance that causes the functionality to break.

In my experience, prefixing the Behaviour Specification Description (before the word “Should”) with “Positive” or “Negative” allows everyone reading the Behaviour Specification or test report to quickly and easily understand whether the behaviour is focused on the positive or negative situation.

Next » Indicate Primary or Secondary Behaviour

« Table of Contents »
Previous « Indicate Positive or Negative Behaviour

The Behaviour Specification Handbook

Effective Behaviour Specification Descriptions

Indicate Primary or Secondary Behaviour

A low-level technical design typically identifies the need for some components that are not immediately obvious from the core business requirements. Some software components in a solution may exist purely to enable or support the functionality of other components that are more obviously required. Similarly, even within a component that exists directly to fulfil a core business requirement, some behaviours within that component may exist purely to enable or support other behaviours.

To help team members better understand the solution and design, it can be helpful to distinguish between these two types of behaviours:

• Primary Behaviours; and
• Secondary Behaviours.

A Primary Behaviour is a behaviour that has been identified and defined as a direct result of attempting to fulfil a core business requirement. Examples of Primary Behaviours include:

• Validation logic;
• Notifications of expected error messages;
• Business rules (including auditing);
• Business errors; and
• Workflow or routing logic.

A Secondary Behaviour, in comparison, is typically a lower-level behaviour required in the solution in order to enable or support the functionality of a Primary Behaviour. These types of behaviours typically are not thought of or identified by business people. A Secondary Behaviour is in no way less important than a Primary Behaviour — in fact, from one perspective, a Secondary Behaviour is more important because a specific Primary Behaviour is dependent upon and cannot function correctly without that Secondary Behaviour. Examples of Secondary Behaviours include:

• Exception handling;
• Transaction or data consistency concerns;
• Data storage and retrieval;
• Performance concerns; and
• Logging functionality.

In my experience, including “Primary” or “Secondary” in the Behaviour Specification Description allows everyone reading the Behaviour Specification or test report to quickly and easily understand whether the behaviour exists directly to fulfil a core business requirement or is required due to lower-level, secondary concerns.

Next » Unique Within Their Feature File

« Table of Contents »
Previous « The Behaviour Specification Writing Meeting

The Behaviour Specification Handbook

The Behaviour Specification Writing Process

Meeting Milestone 1 — Background Context and Requirements Overview

As an introduction to the meeting, please encourage the attendees to ask questions at any time, and ensure that all relevant feedback is recorded.

Start the Behaviour Specification writing meeting with background context about the User Story. It is always useful to set the scene by walking through the business process that leads into this User Story and any other relevant high-level information about the business. (You do have well-defined business processes that you used as part of the requirements analysis effort, don’t you?!)

After the attendees have a high-level understanding of the business process, now dive in and explain the requirements. It is quite useful to create a bullet-point list of all the “core business requirements” and have it visible to the attendees throughout the meeting. This list is very handy during the behaviour identification and describing stage below.

Next » Meeting Milestone 2 — Technical Design Overview

« Table of Contents »
Previous « Meeting Milestone 1 — Background Context and Requirements Overview

The Behaviour Specification Handbook

The Behaviour Specification Writing Process

Meeting Milestone 2 — Technical Design Overview

Now that the attendees have an understanding of the business context and requirements, it is time for a technical representative to present the low-level, initial technical design. Referencing the previously presented requirements, the technical representative should highlight the initially proposed systems and software components, and their relevant interactions.

This is a fantastic opportunity for the entire team (yes, even the business analysts and any other less technically focused people) to learn the technical design and lingo, and also initially challenge the technical design.

Next » Meeting Milestone 3 — Checkpoint

« Table of Contents »
Previous « Meeting Milestone 2 — Technical Design Overview

The Behaviour Specification Handbook

The Behaviour Specification Writing Process

Meeting Milestone 3 — Checkpoint

At this stage, let the attendees ask more questions and note all relevant feedback. As necessary throughout the meeting, evolve the technical design to cater for any issue that has been identified.

If there are significant issues with the requirements or technical design, then consider whether it is prudent to postpone the remainder of the meeting.

Next » What’s Happening In Our Minds?

« Table of Contents »
Previous « What’s Happening In Our Minds?

The Behaviour Specification Handbook

The Behaviour Specification Writing Process

Meeting Milestone 4 — Behaviour Identification

Now that the requirements are understood by the team and there is general agreement that sufficient requirements are known and the technical design is sound enough, the process of writing the Behaviour Specifications can begin.

The first phase of actually writing the Behaviour Specifications involves identifying and writing all the Behaviour Specification Descriptions for the software components from the low-level technical design.

This is the most critical and most difficult part of the writing process. In order to be most effective, everyone who was invited to the meeting actually needs to attend. Each individual perspective is beneficial and necessary for creating the best possible solution that fulfils all of your needs.

This milestone is designed specifically to facilitate and maintain a brainstorming flow where the attendees stay focused at a high-level and look down upon the entire behaviour landscape of a single component. This approach is more efficient and less confusing than repeatedly diving deep, narrowing the focus to a single behaviour, and then resurfacing and trying to recover the wider perspective.

The Goal

Please keep in mind that the goal is to specify all the behaviours that each software component should individually perform. This is a true program specification for a component. The only code that should be written by developers is code that fulfils the Behaviour Specifications. The only test cases that need to exist and be performed (excluding exploratory testing, or independent testing) are those represented by the Behaviour Specifications. Remember this easy guideline: “No Behaviour Specification? No Code! No Test!”

The Behaviour Identification Procedure

The simple procedure to identify and describe the behaviours to be delivered is:

1. Carefully examine the low-level technical design and pay attention to all the different software components;

2. Ensure that the team understands how each software component fits into the overall solution;

3. For each software component, one-by-one, narrowly focused on just one component at a time, answer the following question:
   
   "Within the context, boundary and responsibility of just this software component, what are the behaviours this component should perform in order to fulfil all the requirements?”
   
   Of course, now is a great time to refer back to that bullet-point list of core requirements; and

4. Summarise and describe each identified behaviour individually as a Behaviour Specification Description. For more information, see the chapter Effective Behaviour Specification Descriptions.

Next » Meeting Milestone 5 — Step Writing

« Table of Contents »
Previous « Meeting Milestone 4 — Behaviour Identification

The Behaviour Specification Handbook

The Behaviour Specification Writing Process

Meeting Milestone 5 — Step Writing

In the previous milestone, all the Behaviour Specification Descriptions were identified and written. Depending on the size of the overall solution for the User Story, often it is worth taking a short break before proceeding, primarily to allow the meeting attendees to have a rest and gather their own thoughts.

This second phase of actually writing the Behaviour Specifications involves writing the individual steps that further specify each identified behaviour.

The process of writing the steps for a behaviour is mechanical in nature, being a simple matter of following the Gherkin syntax and elaborating on the details of each behaviour previously identified. Depending on the maturity of the team, and since this phase is more mechanical and comparatively simple, it can be optimised by reducing the attendees, or even just have one person write each step, and send out the finished feature file to everyone for review.

See the chapter Effective Behaviour Specification Steps for more information.

Next » Meeting Milestone 6 — Test Types

« Table of Contents »
Previous « Meeting Milestone 5 — Step Writing

The Behaviour Specification Handbook

The Behaviour Specification Writing Process

Meeting Milestone 6 — Determine Test Types

At this point in the process, the Behaviour Specification Descriptions and steps for a given software component have been written. This final milestone is the most appropriate time to review all the behaviours and decide what type of test each Behaviour Specification should be implemented as, and add an appropriate “@tag” in a line above the description. As you do this, please remember the Testing Pyramid and keep in mind that there should be many more Unit Tests in comparison with Integration Tests.

Some technologies (especially older ones) however, make Unit Testing too difficult or even impossible. When performing this milestone, the team already should have a good understanding of the technology that will be used to implement each software component, and how viable Unit Testing is. If you find yourself in a situation where a component cannot be Unit Tested, then do your best to test at the bottom-most pyramid level as possible.

As a team, review each Behaviour Specification and ask “Can this behaviour be tested as a Unit Test”? The developers typically are in the best position to answer that question, since they best understand the technology and are the ones who would write the automated Unit Tests. I recommended tagging Unit Tests with “@UnitTest” just above the Behaviour Specification Description.

If on the other hand, the test would require the software component to be deployed into a test environment, then it can be classified generally as an Integration Test. I recommend tagging Integration Tests with “@IntegrationTest” just above the Behaviour Specification Description.

The team also needs to decide and agree whether they think there will be enough time to do the automation of each test, or whether the test should be performed manually, at least, for the short-term. Considerations for this can include:

• The Testing Pyramid and the idea of testing at the most appropriate level;
• Whether the behaviour can be implemented as a Unit Test versus an Integration Test;
• Resourcing and skill issues;
• Technical complexity — perhaps it might be too expensive or not technically feasible to develop the test automation; and
• The perceived risk and value of a behaviour.

After considering the trade-offs, for any test that is unlikely to be automated within the necessary timeframe, I recommend that in additon to the tags “@UnitTest” and “@IntegrationTest”, also tagging those tests with “@Manual”.

Next » About End-To-End Behaviours

« Table of Contents »
Previous « What Are Behaviour Specifications?

The Behaviour Specification Handbook

Behaviour Specifications

No Other Test Cases Are Necessary!

Within a software development team, no test cases other than those represented by the Behaviour Specifications are necessary.

Behaviour Specifications Are Comprehensive

Behaviour Specifications literally are the functional specifications of software components. The specifications for a given software component should be comprehensive and unambiguous. If that is not the case, then team members including developers and testers will not know about all the functionality they are supposed to deliver, and the solution delivery will fail.

No other test cases are required! The logic of this statement is simple — since program specifications need to be comprehensive, then no other tests are needed as all possible test cases already should be covered by the specifications.

The fact that Behaviour Specifications are comprehensive and precise is good news for those businesses interested in having their developers coding in distributed and remote teams.

About Test Independence

With this statement about no other test cases being necessary, I am referring specifically to and recommending a software development team structure and operating model where there are business analysts, developers and test analysts closely collaborating. The goals of the development team are to achieve a cost-effective, streamlined, successful delivery of a solution with an agreed level of quality assurance.

Due to the close collaboration of the team members and common desire to prevent unnecessary duplication of testing effort, the test analysts are operating within the same team and cannot, as described by the International Software Testing Qualifications Board (ISTQB), provide a high-level of test independence. Depending on how the team operates however, there certainly could be a medium-level of test independence. For many clients, projects and solutions, this approach is both efficient and sufficient, and it is specifically within this operating context that I state no other test cases are necessary.

For life-critical systems and solutions however, more rigour is required and there should be a high-level of testing independence. In that case, a separate, independent team or company would perform testing in addition to that performed by the software development team. The additional testing certainly overlaps and duplicates significant amounts of the testing effort performed by the development team. It also requires a lot more time, resources and cost. This additional testing however, is performed outside of the software development team, outside the practice of BDD, and is thus outside the scope of this handbook and the presented recommendations.

Likewise, any other phase of testing that is not performed by the software development team is excluded from the statement of no other test cases being necessary. For example, User Acceptance Testing (UAT) is excluded since it is performed by the business and not by the software development team.

Change Will Happen

As the team progresses through the analysis, development and testing phases, new information may emerge and deeper levels of understanding are reached. This is a natural part of the process and it cannot be avoided. A developer might be in the depths of coding part of the solution and see a situation that has not been specified yet. Alternatively, a business analyst may have a random water cooler discussion and find out more complicated business logic that needs to be accounted for. However it happens, someone will think of another requirement, feature, behaviour, scenario or test case that they believe should be specified. When that happens, carefully discern the situation and ensure that it is not covered already by an existing Behaviour Specification. If necessary, add more Behaviour Specifications or tweak existing behaviours where appropriate.

For continuous improvement purposes, it can be useful to maintain a “beginner’s mind” and try to learn and understand why a behaviour was not identified initially in the Behaviour Specification writing meeting. Keep in mind though that in many cases, timing is everything and there may not be anything that could have been done better.

Next Page » Developers: No Other Automated Tests!