[Software Engineering] BDD adopts strategies from the inside out

There is an obvious but overlooked strategy for adopting BDD that is brilliant.

A widely adopted BDD can make a difference. It's just a matter of sharing the same example, with the same consensus on the three main roles of software development. This makes a difference because you reduce misunderstandings, duplication, and useless functionality. It works because it focuses on doing the right function, rather than doing the right function.

Classic BDD Adoption Strategies

The classic strategy is to teach the three main characters to collaborate through the Gherkin. Business people learn to write scenarios, developers translate them into code, and QA validates them. But there's a common problem in this adoption: Gherkin is a programming language that businesses don't know how to code.

Starting to write Gherkin has a secondary effect: developers often think of business as an undisputed authority. Therefore, developers do not have the courage to help enterprises fix the scene. QA has more success with this because they see Gherkin as a quality test where they have the final say on quality.

This is where the problem lies. Developers, the only ones who can get programming languages ​​right, are too busy and too scared to adopt them early. As a result, adoption fails and ends with one of two possibilities: BDD stops, or BDD continues to be suboptimal, never reaching its full potential.

Adopt strategies for BDD from the inside out.

This tactic is so obvious that I don't know how we haven't noticed it.

BDD is the needs of the developers, not the business, nor QA. Developers create it to satisfy its needs, and it spreads. BDD was so powerful in the hands of developers that it continued to grow and spread to this day. So, why not replicate this strategy?

The inside-out BDD adoption strategy is to mimic the creation of BDD itself, but at a faster pace. It's from the inside out, as it starts with developers and unfolds through business and QA. In this strategy, BDD is not something taught, but something desired.

To understand why this work, we need to understand the problems developers face in their daily work. Developers receive instructions written in a vague language, which they must interpret and implement. Once they're done, QA reviews their work. QA adds its own standards, and QA may come up with different needs and requirements. Developers are guessing and redoing.

BDD can be presented to developers as a tool to avoid guesswork and repetition. Before any work, the developer can correctly write the Gherkin scene if something is unclear. They'll use it as a business example, and because it reads like English, they'll have a clear response. The same goes for QA, if they think there is any edge case that might lead to discussion, they can write the scenario before writing the code, and then ask QA. For developers, Gherkin becomes a tool for solving doubts and avoiding duplication.

Later, as Gherkins come and go, businesses learn about Gherkins and how they affect product behavior. They learn something that can only be learned by doing. The same goes for QA. Both of these roles are learned in the day-to-day practice of developers, so in the end, it all comes together.

Many people wonder what Gherkin is? Gherkin is a business-readable, domain-specific language created specifically for behavioral description. It enables you to remove logical details from behavioral tests.

This article https://architect.pub/bdd-inside-out-adoption-strategy
Discussion: Knowledge Planet [Chief Architect Circle] or add WeChat trumpet [cea_csa_cto] or add QQ group [792862318]
No public
 
【jiagoushipro】
【Super Architect】
Brilliant graphic and detailed explanation of architecture methodology, architecture practice, technical principles, and technical trends.
We are waiting for you, please scan and pay attention.
WeChat trumpet
 
[ca_cea]
Community of 50,000 people, discussing: enterprise architecture, cloud computing, big data, data science, Internet of Things, artificial intelligence, security, full-stack development, DevOps, digitalization.
 

QQ group
 
[792862318] In-depth exchange of enterprise architecture, business architecture, application architecture, data architecture, technical architecture, integration architecture, security architecture. And various emerging technologies such as big data, cloud computing, Internet of Things, artificial intelligence, etc.
Join the QQ group to share valuable reports and dry goods.

video number [Super Architect]
Quickly understand the basic concepts, models, methods, and experiences related to architecture in 1 minute.
1 minute a day, the structure is familiar.

knowledge planet Ask big names, get in touch with them, or share private information.  

Himalayas Learn about the latest black technology information and architecture experience on the road or in the car. [Intelligent moments, Mr. Architecture will talk to you about black technology]
knowledge planet Meet more friends, workplace and technical chat. Knowledge Planet【Workplace and Technology】
Weibo 【Smart Moment】 smart moment
Bilibili 【Super Architect】

Tik Tok 【cea_cio】Super Architect

quick worker 【cea_cio_cto】Super Architect

little red book [cea_csa_cto] Super Architect  

Thank you for your attention, forwarding, likes and watching.

Guess you like

Origin blog.csdn.net/jiagoushipro/article/details/131672268