While It’s Compiling is a continuing series of interviews with experts across a range of bleeding-edge technologies and practices, exclusive to Skills Matter. Be sure to subscribe to this blog for future interviews, or follow us on Twitter.
Find out who we’ll be interviewing next, and get a chance to put your questions forward with the hashtag #whileitscompiling.
Mary Thorn is a Director of QA at ChannelAdvisor in Morrisville, North Carolina, and she has a broad testing background that spans automation, data warehouses, and web-based systems in a wide variety of technologies and testing techniques.
We caught up with Mary ahead of her talk at CukeUp! New York City on the 30th September.
In your talk at the upcoming CukeUp! Conference in New York you’ll be looking at the promises of Behaviour-Driven Development (BDD) and Acceptance Test Driven Development (ATDD), namely, greater collaboration between Product Owner & team and focus, along with an increase in the value produced. Without giving too much away, can you give us a quick insight into how you see this working?
I feel that “How to implement BDD?” is the million dollar question. I’ve been successful on four projects and, even though I feel I have a lot more to learn, I want to share my experiences of what’s been successful. BDD can be implemented in Waterfall and Agile processes, with or without automated testing. My experiences have all been in an Agile process with automated testing to back it up, although I have examples from my current job of Waterfall projects who have implemented BDD without automated testing.
The first step in the process for me has been selecting which automation tool to use. Next, I start to introduce the topic of BDD by either a lunch-and-learn or community of practice event. The goal of this step is to start to explain the practice and benefits. My hope is that someone in the room will help me champion this process. A lot of times, the QA team reporting to me are yearning for more collaboration and to be involved in requirements definition, so it is not a hard sell. The biggest pushback typically come from the Product Owners and Business Analysts because they feel that we are adding more work to their plate. In reality we are not, we are adding more upfront work, but less work and rework later in the process.
Next I start to partner and build relationships with the Product Owners, Business Analysts, Functional Analysts, Scrum Master and Development Manager. I encourage them to engage in what we can do as a team to build a better product and make the clients happy. I also start to plant seeds with the QA team to bring up BDD as a retrospective item for the team to try. The next step is running a BDD workshop for the team. Once everyone is trained after the workshop, I encourage the POs or BAs to take just one or two stories out of the next sprint and to take a stab at writing the Gherkins.
After having one-to-two stories with feature files in hand, the PO will hold a grooming session with the entire team (including, PO, Dev and QA) to discuss. The PO will introduce the user story,the GOAL they are trying to accomplish, the acceptance criteria, and the scenarios. Most of the time the scenarios will be 75% of the conversation. During the discussion you will add, remove, and refine the examples as you discuss. At this point the “Whole Team” now owns the feature files and examples, not just the PO or QA. Once everyone agrees on the scope, the team will then estimate the size of the story in points.
Next is sprint planning with the Whole Team. I ask the team to bring the feature files as well as the User Stories to help when breaking stories into tasks. I have found by doing this, estimates are smaller and more accurate as most examples are covered.
Once the sprint starts, Dev and QA review the feature file together one last time to make sure it’s complete. Any additional scenarios at this time should also be reviewed with the whole team. Then developers use TDD to code the scenarios in the feature file. Due to the fact the developers already have the tests from the examples and scenarios they can go ahead and write their equivalent unit tests. The QA automation engineer can start developing in parallel as long as they have discussed with the developer the things that the developer needs to do to make that story “automatable”. The goal is that Dev and QA finish at the same time and that, when all the tests “Go Green”, then the PO can accept that the story is “Done” because all the scenarios and examples pass.
After doing this for almost 3 years now, I’ve seen these benefits:
- Expectations, Goals and Business Value are communicated and challenged and clarified with every story
- Defined Scope
- Overlooked Requirements Revealed
- Tangible Reference Materials
- Accurate Story and Task Estimations
- Deliberate Collaboration Between QA/DEV/PO
- Increased Productivity
- Decreased Bugs from SIT/UAT/PROD
- Commitments are met (and often times exceeded!)
With that in mind, what are the main factors that can pose a threat to getting BDD right? Are there any classic pitfalls you see recurring again and again?
My main pitfall I run into time and time again is that the Product Owners don’t think it is their responsibility to write their acceptance criteria in acceptance test format. This role is solely the QA’s responsibility and that it is just putting additional work on their plate. What they don’t understand at the beginning is that the discussion helps to uncover missing requirements and helps the team build it right the first time. I eventually get there, but it’s a pitfall that happens over and over again.
Eric Evans, who coined the phrase ‘Domain-Driven Design’, is speaking as well this year. What do you think are the main connecting threads between DDD and BDD?
I have not worked on a project yet where the DDD concept was used. However, I have kept up with the community and I think I understand the concepts. I still think these two concepts (BDD and DDD) have the same goal which is “creating conversations so that you build the right thing the customer wants the first time”. These are just two different ways to meet that goal.
This isn’t the first time you’ve spoken at CukeUp!, and we’re delighted to have you back after your talk last year. As the conference is built to be as much a social event as a series of talks, during your experience last year were there any conversations you had with speakers and delegates which have shaped your work or ideas over the past year?
They have! I am super excited about the Cucumber Pro tool that is coming out. This is a much needed feature in our open source community and one that I have yearned for the past four years working with Cucumber. I currently have left the company I worked at last year who used Cucumber and now I use it’s sister tool Specflow and I hope I can convince Aslak [Hellesøy] to integrate with it in the future. I might have to request a name change though 🙂
And obviously, you’re returning to a CukeUp! that’s slightly different from last year with the addition of two half-day workshops exploring non-technical applications of BDD. Do you feel there is a wider need for non-technical solutions in BDD at the moment? Essentially, do you feel that automation runs the risk of degrading or avoiding regular and constant communication
Great question, and one that I am all to familiar with. Both companies that I came into that had implemented Cucumber before I got there said they were BDD shops and really were just using it for automation purposes. This tool is great for automation but even better for communication and I do feel we are running a risk of avoiding regular and constant communication. However if implemented correctly, you can put in process steps that avoid this and I hope to discuss that in my talk.
London is blessed with a variety of conferences and meet-ups that support the BDD community. You’re based in North Carolina, is there a strong ‘after-hours’ software community there?
There absolutely is. The ‘Research Triangle Park’ area is one of the fastest growing cities in the US for IT jobs. We have several Agile Meetup groups and Agile Testing and Automation groups. This year I co-chaired our Bi-Annual TISQA testing conference, as well as our first Agile conference, TriAgile.
Mary will be speaking at this years’ CukeUp! conference Tue, 30th Sep – Wed, 1st Oct at DUMBO Loft, New York City.
She will be joined by a host of leading names from the world of Cucumber including Aslak Hellesøy (creator of Cucumber & co-founder of Cucumber Ltd.), Eric Evans, George Dinwiddie, Paul Rayner and many more!
This two day conference will explore various aspects of BDD in this New York community event. CukeUp! is organised and curated in partnership with Cucumber Limited and also runs annually in London.
Click here to book your ticket now!
The Skills Matter Blog 