We recently gave a presentation at the Romanian Testing Conference on “Behavior Driven Development” in Python. We didn’t know exactly what to expect from this conference when we first heard of it. We were looking forward to attending, as we were interested in the presentations’ topics and the overall experience of a conference on testing and software development. So when the chance appeared of actually being presenters, we said “Why not? We have a lot to learn, no matter the outcome.”
We prepared a topic revolving around “Behavior Driven Development” and what our challenges are from applying this methodology on our projects. We knew that although most have heard of BDD, there are fewer who have had the chance to try it first-hand. So we decided that instead of proposing a presentation that recites definitions and best practices, we would prepare something that appeals to the public: our understanding of BDD, not the complex notions you can find on the Internet, how are we applying it and what are the challenges we are facing. Combining this with a demo of how tests can actually be written with BDD, we felt that we had a topic that would draw attention and pose some interesting questions.
It was a simple idea, and it worked. We were selected to hold one of the two local presentations and we had little over 3 weeks to prepare. Using “Specification By Example” as guideline, as well as the knowledge gained when applying this methodology, we started drafting our slides, modifying them with each rehearsal. We wanted the slides to express two key factors: communication and collaboration. Actually, I feel that having just these two words written, we could have spoken of BDD, and the people would have left with a very important conclusion: Quality is a team effort.
After several rehearsals held for our colleagues, the day has come to present the topic to a much larger audience. Oddly enough, I was not nervous. I was curious about how it’s going to develop, and we sincerely hoped that we would get the curiosity of some of the conference’s attendees. We watched one presentation before, and I was calmly waiting our turn to express our view of BDD.
And it started. Curious people were watching and I tried not to think of their expectations. I just wanted for them to get a better idea of what BDD is and what problems it could solve. The 50 minutes allotted almost flew by. I say almost, because at some point, I felt that we’ve went through most of the information, and we still had around 30 minutes to go. So I decided to stop following the script rehearsed before. And we tried to communicate with the public. To create a relationship with the people attending and to deliver the message in a way that is not condescending and it can actually raise some interest on the topic. And those 30 minutes really flew by 🙂
Following was the Q&A panel, with Scott Barber as chairman. Several questions ensued, most of them being of a more “philosophical” nature: “When does testing stop?”, “What can’t you automate?”, “What is the career path ahead for a tester?”, and so on. We tried to express our opinions on these matters, but I feel that one should find the answers based on each project and team’s needs and particularities. Unfortunately, there is no secret recipe that could ensure success and team unity, but nevertheless, we were happy we had the opportunity to share our ideas and concerns on these topics.
We liked that different ideas were expressed, and we left the conference with a general consent that Testing is everyone’s responsibility and you’re better off without a dedicated QA team. More exactly, everyone is a software engineer, with some specializing in testing.
Overall, it was an interesting experience, and we were happy to be part of it. Most of all, we are happy to see others share the same ideas, and it’s encouraging to know that testers get their voices heard more and more.