In my last post, I introduced our new blog series, Bria on The Road. For the next month, I’ll be taking you all along with me as I travel the world in search of the latest and greatest trends going on in the software testing industry.
Stop #1 on my tour was 121 Agile Testing and Test Automation in Atlanta, GA.
What’s for Lunch?
A perk to traveling all over the world is seeing friends where they work! One of my best friends works in Atlanta, so I decided to meet him for lunch. Of course we decided on Chick-fil-a. I was so excited until I had a horrible realization—it was a Sunday, and Chick-fil-a was closed. We had to settle for the next best thing- the Publix chicken tender sub… a symbol of happiness and love.
Now, why is any of this even remotely important or relevant?
While I was at 121 Agile Testing and Test Automation, we had a great lineup of speakers talking on a variety of things ranging from the internet of things (IoT) to quality BOTs, mobile automation and automation in an agile world. One session I particularly enjoyed was Sameer Bendre’s talk on Why BDD Matters to Agile Testing.
Where does BDD Come into Play?
I have heard a lot about Behavior-Driven Development (BDD) recently, starting with Seb Rose’s talk about it at our recent meetup, followed by discussions with many testers who were just starting to implement BDD, and now I was listening to Sameer talk about it in Atlanta. So, I thought I’d share what I’ve learned.
BDD is a software development process which stems from test-driven development (TDD). BDD focuses on software development with a focus around both business interests and technical insights to support the software development process. Because of this, often times there is an investment in tools that is necessary to support this development style.
BDD is made up of three practices:
- Discovery—“the journey of developing software, is always a journey of discovery and language,”-Rose stated at our meetup last month. BDD works well when a developer or tester and business person get together and continue to ask “why” to one another.
- Formulation—formulation takes discovery and documents those discoveries using business terminology… why does this matter? Because teams can now communicate in a shared domain language. It is important to note, this communication is in business language—not an implementation language.
- Automation—the area where tools play the most important role by adding automation to the testing efforts that support the shared domain language mentioned above.
Automation, and the tools that make the automation happen get a lot of attention when we talk about BDD. But what are the two keys to BDD?
Collaboration and communication.
To make this easier to understand, let’s return to my lunch with my best friend Jeff that I mentioned at the beginning of this post.
Let’s pretend I am the business analyst, and Jeff is the developer. He would create pending specifications for our lunch in Atlanta together during our discussion:
- Lunch should happen during lunch hours
- Lunch should have two people present
- Lunch should take place at Chick-fil-a
The acceptance test may be written like this:
- As two good friends who want to catch up, Jeff and Bria should go to lunch together so that we can eat great food and talk about life.
The acceptance criteria could be something like this:
- Given that Bria and Jeff haven’t seen each other in a while, when lunch occurs, then they should leave with happiness after a tasty meal and great conversation.
Notice, all of the above specifications are phrased in business language—not any type of implementation language.
So, after doing this, Jeff may come back to me for more clarity and ask… “Hey Bria, what do you consider “lunch hours? Is it okay if more than two people are present? What should we do if Chick-fil-a is closed?” After doing this, we can discuss the answers together.
While this example may be a little far-fetched…it still highlights the most important thing when it comes to BDD, a shared language.
BDD and Agile
How does this all link back to being agile? BDD borrows from agile the fact that all unit tests should be specified in terms of the “desired behavior,” also known as the specifications made above. The specifications should be tied directly to a business value to drive the software development and is often times referred to as an “outside-in” activity. Special tools are available for agile teams looking to start practice BDD.
- BDD boils down to two important things: collaboration and communication.
- There are three practices of BDD: 1. Discovery 2. Formulation 3. Automation
- Special tools are often necessary to practice BDD
- If Chick-fil-a is closed, I highly recommend a chicken tender sub from Publix
Follow the author @Bria_Grangard