I think every developer wants to write fewer bugs – but for all their wanting, I have still seen many, many bugs in my career. Even though the developers work carefully and do their best to prevent bugs, we still deliver too many bugs into Production.
If Conscientious Hard Work Doesn’t Prevent Bugs, Then How Can We?
We must start by understanding the causes of bugs – bugs come in two types:
Little-B bugs
Little-B bugs are those bugs where the code doesn’t do what the developer intended – the text entry box isn’t large enough, or sorting doesn’t work, or the wrong data is returned by a query. We can prevent these from getting to Production by careful code reviews, careful QA, or good test automation delivered early.
Big-B Bugs
Big-B Bugs are the ones where the code does exactly what the developer intended – it just isn’t what the customer wanted. These are immensely costly; your developers may have spent two or three sprints writing really good, clean, highly maintainable code that does the wrong thing!
- Careful code reviews won’t prevent these; if the developers misunderstood what the customer wanted, then they will review the code to verify that it does what they mistakenly think the customer wanted.
- Careful QA won’t prevent these if the QA team has the same misunderstanding as the developers about what the customer wanted.
- Good test automation won’t prevent these if the QA team has the same misunderstanding as the developers about what the customer wanted.
The only way to prevent Big-B Bugs is to ensure that the Product Manager, Business Analyst, Developers, and QA all have exactly the same understanding of what the software is supposed to do. Misunderstandings about the purpose are caused by miscommunication around the requirements – so we must start there.
Preventing Both Types of Bugs
The only way to ensure that everyone has exactly the same understanding of what the software is supposed to do is to change the way we write the requirements. Specification by Example/BDD makes two fundamental changes in the requirements writing process:
- SBE/BDD says that the requirements must be written collaboratively – BA, PM, Developers, and QAs working together to define the terms they will use and then to write the requirements using carefully defined and consistent language. Done well, this can virtually eliminate Big-B Bugs (and there are multiple companies that have reported this).
- SBE/BDD says that requirements must be written using concrete examples – using concrete examples makes it much easier to think of other important examples, and to find all of the important examples (boundary conditions and corner cases, unhappy paths).
Done well, SBE/BDD lets us arrive at a collective understanding that looks more like this:
SBE/BDD also makes it possible to deliver test automation in-sprint, before the developers have finished writing the code. Having automated tests makes it easy for the developers to check their work before they even check code into the branch, and this can virtually eliminate Little-b bugs.
I have led teams through the transition from delivering too many bugs, to delivering so few bugs that they no longer needed a bug tracking system. I would be glad to share how we did that; please contact me if you would like to discuss it.