The Secrets of Successful Collaboration - BDD

[TanyaYatskovska]

Hi our BDD TestComplete users,

I want to share with you a great webinar presented by Seb Rose, developer, trainer, coach and author of "Discovery - Explore behavior using examples". Seb reveals the secrets of successful collaboration in BDD.

>> Request the webinar here

What do you think about this approach? How does the testing process set up in your organization at the moment?

[AlexKaras]

Hi Tanya,

Thank you a lot for sharing a link to the webinar. It is really great and contains several things worth to be considered.

On the other hand, webinar materials confirmed my opinion that for the *functional end-to-end tests automation* plain BDD approach is hardly usable. Some mixed approach might be considered, but only after thorough preliminary consideration, exact process establishment and responsible roles assignments. (Which means a reasonable level of bureaucracy and decreased probability of successful implementation.)

[sebrose]

Hi Alex,

I'm glad you got some value from the webinar - which was focussed on collaboration rather than Behaviour Driven Development (BDD).

BDD is not a QA activity, although one of the by-products of following all three BDD Practices (Discovery, Formulation, Automation) is a certain number of automated scenarios. The primary goal of BDD, however, is reaching a shared understanding of the required behaviour -- and capturing this using business-readable language.

The majority of the behaviours that we describe in BDD scenarios are quite narrow, but there is a place for "Journey Scenarios" that document wider, end-to-end processes (see our forthcoming book, Formulation). These are useful to give the reader of the documentation an overview of how users will interact with the system and are not intended to replace other forms of testing that your organisation may require.

It is our experience that product teams adopting BDD don't experience increased bureaucracy as a result -- and their product is higher quality and cheaper to deliver.

Hope that helps

Seb

[AlexKaras]

Hi Seb,

Thank you a lot for the followup comments.

Yes, I absolutely agree as for Discovery and Formulation and this is what was really useful at least for me.

I also agree as for the shared understanding expressed using common language.

> The majority of the behaviours that we describe in BDD scenarios are quite narrow [bolded by Alex]

This is exactly what I meant from practical point of view of tests automation practitioneer: simple narrow scenarios may contain all details required for successful automation.

However wide "Jorney" scenarios for end-to-end tests usually require a lot of details for successful automation. With this level of details, the scenario will be absolutely irrelevant for business because it naturally does not need this level of details.

On the contrary, automation of the high-level business scenario will result in that a lot of cases that can happen during test flow will be handled by test author according to his own understanding without been documented in scenario. As a result, we will not get the test that, by definition, verifies the requirement (even incorrect one!). Instead, we will get something like automated exploratory scenario validation done from the subject matter expert's point of view. And this point of view may differ from the (possibly incorrectly formulated) requirement.

And, unfortunately, I did not hear about BDD implementations that support tree-like expandable structure when at the root we can have a business statement and expand it down to the level required by Sales, Marketing, Development, Testing and so on.

This is what I meant  in my initial reply to this thread.

[sebrose · Accepted solution]

Hi Alex,

First, BDD is focussed on agreeing and documenting behaviours, not testing. This may be why you don't see BDD implementations that support tree-like expandable structures.

In all but the most trivial systems, exhaustive path coverage is unattainable. Instead, metaphors such as the test automation pyramid were created to help us achieve confidence in a sustainable way.

• Narrow tests (at the bottom of the pyramid) give us confidence that the code satisfies the detailed requirements.
• Further up the pyramid there are tests that exercise interactions between a small number of components. This gives us confidence that the protocol/contract between the components has been correctly interpreted/implemented.
• Finally, at the top of the pyramid, there are a few tests that exercise the whole of the system. These should be thought of as smoke/deployment tests, giving us confidence that the system has been deployed correctly, is talking to the right end points, has the correct authentication tokens for the environment etc. Broadly, that it "hangs together".

Combining these different types of test together can give us confidence that the system behaves as requested -- especially if the test doubles used to ensure isolation for the narrow and protocol tests are covered by contract tests. Other testing is also needed: exploratory, penetration, load etc. I've written a couple of blogs that partially cover these topics with this here and here.

When writing Journey Scenarios, we need to ensure that they are written using business language. They should express the intent of what the actor interacting with the system is trying to achieve, rather than the mechanics of how they will achieve it. The technical details will be wrapped up in the automation code (step definitions) rather than being exposed to readers of the specification. However, the automation code is also used (and validated) in the narrow scenarios that guided the original implementation.

To your final point, about supporting other stakeholders (e.g. Sales & Marketing), I have seen implementations where a single feature had several feature files, each of which targeted a different audience (in a recent example they were Sales and Actuarial). This is hugely beneficial for communication, but is definitely not motivated by a desire for exhaustive test coverage.

In summary:

1. BDD is not focused on testing
2. Exhaustive path coverage is unattainable (so we lean on the test automation pyramid)
3. Journey scenarios that use business language can be understood by (and are interesting to) less technical colleagues
4. Documentation can (and should) be tailored to the specific stakeholders with whom you are collaborating

Thanks

Seb

[AlexKaras]

Hi Seb,

Thank you again for your detailed comments, much appreciated indeed.

> BDD is not focused on testing
This is a key point.
And I think that this is the thing that must be understood by both, those who do initial 'business-faced' part of work and those who do a technical one.