The Future is Finding Zero Bugs (in QA)

Depending on QA to catch bugs is inefficient:

• It is far cheaper if we never create the bugs
• It is far cheaper if we catch them before the Developers open a pull request

Depending on QA to catch bugs also means that QA takes the hit if requirements are late and the Developers take too long. The date doesn't move; QA gets crunched.

Shifting all the way left—so far left that we prevent bugs from ever being written, and so far left that we deliver automated tests to the developers before they finish coding—eliminates these problems. BUT, the only way I know to do that is to use Specification by Example/BDD, and that is a methodology change that requires training and coaching, time, and buy-in from the Product Owners, Developers, and QA. I have tried it without that buy-in, but it doesn't work well.

However, with that buy-in and the appropriate training and coaching I have seen a team deliver monthly releases for a year—and only two bugs!

In this presentation you will learn:

• What is Specification by Example/BDD?
• How is it different from standard Agile development methodologies?
• How does it prevent bugs from being created?
• How (and how much) does it shorten the development cycle?
• How can you introduce it into a product development team?

Leslie Brooks

I have decades of experience in QA and specifically in automated testing, but I am always laser focused on value. Automated tests that cost too much to maintain don't deliver the value the we should demand. I love teaching about Specification by Example/BDD; I love the tremendous improvements it can bring to the entire organization. When we are able to write better requirements, write better code (and fewer bugs), find and fix bugs faster, and deliver better quality code faster, then I feel an enormous sense of accomplishment.