Forum Discussion

TanyaYatskovska's avatar
TanyaYatskovska
SmartBear Alumni (Retired)
5 years ago
Solved

The Secrets of Successful Collaboration - BDD

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...
  • sebrose's avatar
    sebrose
    5 years ago

    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