I’m continuing to answer questions that were asked during my session “Are BDD and test automation the same thing?” at the Automation Guild conference in February 2021. This is the fourth of five posts.

1. Why should automation be done by the dev team?
2. Isn’t the business-readable documentation just extra overhead?
3. What’s wrong with changing the scenarios to enable automation?
4. Can all testing be automated?
5. How can Cucumber help us understand the root causes of failure?

The question​

Isn't the goal of repeatability for refactoring confidence, not test confidence?

I’m continuing to answer questions that were asked during my session “Are BDD and test automation the same thing?” at the Automation Guild conference in February 2021. This is the third of five posts.

1. Why should automation be done by the dev team?
2. Isn’t the business-readable documentation just extra overhead?
3. What’s wrong with changing the scenarios to enable automation?
4. Can all testing be automated?
5. How can Cucumber help us understand the root causes of failure?

The question​

Why many times I find myself changing the BDD statements once I start automation, as there is certain information needed between steps? BDD framework is supposed to involve many stakeholders and yet I feel the statements are to be written in a very stringent fashion.

After my talk called “Are BDD and test automation the same thing?” at the Automation Guild conference in February 2021 there were more questions than I could answer in the available time. This is the second of five posts answering the five most important ones:

1. Why should automation be done by the dev team?
2. Isn’t the business-readable documentation just extra overhead?
3. What’s wrong with changing the scenarios to enable automation?
4. Can all testing be automated?
5. How can Cucumber help us understand the root causes of failure?

The question​

Doesn't adding something like SpecFlow to interface with something like Selenium just add an extra code base that must be maintained? Does the benefit justify the extra work?

I’ve been writing and talking about test automation and BDD for quite a while now. In February 2021 I gave a short version of a talk called “Are BDD and test automation the same thing?” at the Automation Guild conference to explore their relationship and address the confusion that exists in the industry.

The conference organiser, Joe Colantonio, hosted a Q&A session after the talk, but there wasn’t enough time to answer all of the questions. Handily, he provided me with a list of all the questions asked, along with his estimation of their “sentiment” – either neutral or negative. In this series of posts, I am going to address the five unanswered questions that he marked as having a negative sentiment.

• Why should automation be done by the dev team?
• Isn’t the business-readable documentation just extra overhead?
• What’s wrong with changing the scenarios to enable automation?
• Can all testing be automated?
• How can Cucumber help us understand the root causes of failure?

The question​

I do not get, why you say the automation part #5 on the graph, should be done by the dev team and never the QA, because it's part of the design process. For example, if a team uses Serenity-BDD with screenplay, which makes it very easy to implement SBEs, shouldn't dev team focus on prod code instead?

Gojko Adzic wrote his award-winning book, Specification By Example, 11 years ago. Last year, he ran an online poll to determine the most popular format for expressing examples and found that Given/When/Then received 71% of the votes.

Gherkin is probably the reason for this win, because:

• Given/When/Then are the core keywords of Gherkin
• Gherkin is the structured syntax understood by automation tools such as Cucumber
• Cucumber is a widely downloaded, open-source tool, available on numerous platforms

So, it might be fair to say that when it comes to documenting and automating examples, “Gherkin rules.” That is not what this article is about.

Over the holidays you voted for different ways to organise feature files. This article shows the results of the survey, an analysis of the votes, and some general ideas on how to organise your living documentation.

Gojko Adzic has been running a series of challenges called #GivenWhenThenWithStyle. This is my solution to challenge #16. You should definitely check out the rest of the challenges and their solutions.

Gáspár Nagy and I have written in more detail about writing and organising feature files in our new book, Formulation.

The winner is…​

Gojko Adzic is running a regular challenge called #GivenWhenThenWithStyle and last month’s topic was how to specify relative time periods. In his “solution” article, he disagreed with the majority of challenge respondents, favouring the use of a long scenario outline containing actual dates.

I have a different take to Gojko, that is more in line with the community response. This article describes my approach – but you’d be advised to read Gojko’s original posts first (and subscribe to the challenge).

Recently my colleague, Theo England, broadcast a question:

We're thinking about running a … one-day class [about BDD] designed for business execs. Tell us the questions we must answer for it to be useful.

We received 60 responses, including some very good questions.

As well as providing valuable input into the design of our upcoming course, BDD for busy people, we felt that we should answer some of the questions in a public forum. This is the second in the series.

“Where does the sign-off of requirements happen – and how is it documented? Can we have full traceability?”

Writing good requirements is a challenge, especially if they’re intended to be understood by someone other than their author. The more complicated a project gets, the harder it is to communicate the requirements in an unambiguous way. It’s easier to ask someone to cut the grass than it is to describe a design for a flower bed.

By the time we get to designing software systems, the complexity is such that requirements are a collaborative effort that need to be recorded in a structured way. During the 20th century, various formal and semi-formal approaches were integrated into a waterfall model – where each project had distinct, gated phases and each phase had defined outputs, such as “requirements specification”. These approaches to requirements management did not remove the risk of project failure, while adding considerable upfront costs that were often unjustified in the rapidly changing business environment.

This month on the Cucumber Podcast, Matt Wynne and Seb Rose speak to Chris Glover, a lead test engineer who has been working in a team which has struggled with some of the common pitfalls of learning BDD. Matt invited him onto the podcast to share that story.