BBT can be your best friend or a nest of nightmares. When using BBT there is a certain mindset needed in order to have a good first impression, so like most, a transition is needed. Thankfully, you don’t have to figure it out alone. There are a few basic principles that were created that help any user become an expert really quickly. I am going to be going over the very first and the most important principle, determining the outcomes first.
In software quality assurance industry, most quality assurance engineers go through the same flow, write test cases for the new feature, test it, automate it, and hope you covered everything. When it comes to BBT, it reduces the amount of steps, and work, trying to figure out each and every permutation out there. When a new feature comes out, all you need to do is figure out all the different outcomes you want to test. I mean, how easy is it just to determine what you want/expect to happen? This will narrow down a lot of the work and complexity needed in ensuring everything is covered. Also, without the added pressure in trying to figure out all the steps to lead to an outcome, you’re just focusing on the feature and its expected behavior.
BBT is a powerful tool, there is a bit of a learning curve and mindset transition, but mastering its principles can make all the difference. This specific principle might be the hardest part of making the transition to a BBT mindset, but once it becomes second nature, everything is easier. The other principles are definitely important as well, they touch on all aspects of BBT. Things like determining the contexts, graphing negative cases in a positive way, keeping it simple, keeping it tester friendly, and keeping it business readable. All these principles work together to make BBT your best friend.