Using Behavior Driven Development to Prevent Communication Failures

Communication is critical in every aspect of our lives. It’s our means for interacting with others. At work, it’s our way of advocating for what we need from other people in order to get our jobs done. At home, it enables us to talk about our day or explain what restaurant we want to go to for dinner.

But what happens when we fail to communicate properly? Miscommunication can cause things to go off the rails. Everyone has had their fair share of arguments with a colleague, friend, or family member because the communication between each of the parties wasn’t very clear.

For example, maybe you tell your wife you have to stay “late” at work on Thursday. How will she interpret the word late?” It’s ambiguous. She might think “late” means an hour, but to you, “late” means more like 2-3 hours, at least.

Sitting at your desk, you might get a call from your wife that night at 8:00pm asking where you are and why you still aren’t home yet. You say, “I told you I had to stay late.” To you that meant you wouldn’t be home for dinner. In her mind however, she interpreted “late” to mean “later than normal, but still available for dinner.” This misunderstanding causes an argument that no one wants, and lots of wasted time and energy. It may seem like a silly example, but it illustrates how important it is to make sure all parties understand when communicating. I can interpret a statement one way, and you could interpret that same statement completely differently.

The Importance of Communication at Work

This is no different in a business context. Miscommunication can cause major issues. And in many cases, maintaining clear communication at work can be even more difficult than at home, because there are usually more parties to communicate with when you’re working on a project. Those colleagues might also be located across the globe.

Take the application development process for example. There are generally three key stakeholders (often referred to as the “Three Amigos”) that are involved: product, development, and QA. Each offers different areas of expertise and looks at problems and requests differently, based on that area of expertise.

What happens many times is that a product owner makes a request of the development team for a certain feature. Two weeks later, once the feature has been developed and tested, the product owner sees the feature and finds that it is slightly (sometimes significantly) different than what (he thought) he had asked for – because the developer interpreted the request differently than the product owner thought he had communicated it. The product owner gets frustrated by this. By the same token, the developer isn’t very happy that she wasted two weeks of her time building a feature that she will now have to spend another week on correcting to align with the product vision.

How can this be avoided?

Practicing BDD to Avoid Miscommunication

Teams that practice behavior-driven development (BDD) are better equipped to avoid these communication failures. With BDD, stakeholders utilize the Gherkin syntax (“Given, When, Then”) in the planning phase of software development. Gherkin is written in plain English and provides the team with a consistent framework to reduce ambiguity and create alignment – before development begins.

Our latest eBook, Bridging the Gap in Communication While Scaling Your Testing Efforts, focuses on how BDD helps teams create a universal understanding in the planning stage, regardless of technical proficiencies.

The eBook highlights the following:

  • How to reduce ambiguity and limit rework
  • Examples of implementing BDD
  • Ways BDD can be more effective with continuous testing

Click here to read the ebook!

BDD Tooling Can Help Facilitate Collaboration

A behavior driven development tool like HipTest can help facilitate collaboration with an interface that is easy to use for business people and developers alike.

With HipTest, the team can quickly define BDD scenarios (acceptance tests) in plain English using the Gherkin syntax. The action words used to define those scenarios can then be reused across different scenarios to help standardize the terminology used across the organization. This makes the business people happy 🙂

Developers are then able to take those scenarios and export them into their favorite coding framework (HipTest supports over 20 frameworks, including Cucumber, Java, Specflow, and Selenium) with the HipTest publisher. This makes developers happy because they can use the framework with which they’re most comfortable 🙂

Finally, for testers using automation, HipTest integrates with your favorite CI/CD tools like Jenkins, Bamboo, and Travis. If you’re performing manual testing, you can simply mark tests as “passed,” “failed,” “re-test”, etc. inside of HipTest. In both cases, the Jira integration makes it easy to track the status of your tests in real-time so testers can be happy too 🙂

Ready to get started with BDD? Try a 30 day free trial of HipTest now!

 

Leave a Reply

Your email address will not be published. Required fields are marked *