What makes a project Behavior Driven?
This article is a guest post written by Alex, an Independent IT QA Consultant, with over 6 years of experience, specialized in infrastructure, telecom, defense and security.
Having been previously exposed to the Test Driven Development (TDD) practices at the beginning of my career in IT QA, the ancestor of current BDD practices, I have had a first-hand experience with the ups and downs arising from a poorly managed requirements development process and learned not to put expectations very high in regards to initial system architecture at a certain scale.
The truth is, more often than not, most software-related projects that were brought during the past decade to Romania had suffered from a poor relationship with the customer/owner, which translated to a poor initial design and/or lack of consistency in what is generally referred to as the “vision” of the project.
Having arrived at 1&1, in my first project I am tasked with implementing behavior-driven development for QA. Standard project management practices usually make QA team members feel quite disconnected from the fact that they too, as well as developers, are part of a larger IT software-as-a-service delivery process. Agile methodology has alleviated this up to a certain point but most of the testing process still is intricately linked to the architecture performed by the development team (and will always be the case when the architects of a solution are biased by their formal education in programming)
At its core, BDD combines an idea about how software development should be managed (that technically is more agile than waterfall), a set of shared tools and a shared process to collaborate on (in our case both for DEV and QA) and the proper skill set mix of a team with the aim of delivering software “that matters”. For most, the main factor of change is rethinking the approach to unit and acceptance testing that was conceived by Dan North in 2009 to address TDD issues that he encountered while teaching:
- Where to start in the process? Common mindset still rules in most software development processes that QA has nothing to do until some development gets done. BDD is a great game-changer for this and the main outcome is the objectivity of the resulting test scope.
- What to test and what not to test? QA has to stop relying on solutions being solved entirely by DEV and contribute to the overall architecture
- How much to test in one go? A testing framework should quantify what to test from the beginning in terms of coverage, with each sprint adding more depth to it.
- How to understand why a test fails? Maybe not so obvious without seeing the bigger picture, but within the boundary of the framework each fail is traceable to its behavior logic rather than to a particular development task
A few years back I had the opportunity to take a course from the Software Engineering Institute that most organizations today in Romania, either directly involved in software architecture or not, would have considered superfluous. Today, as more and more organizations understand the lower operational costs that Agile processes bring to the table, they strive towards moving their project portfolios from being “hero-driven” (as where the project “dies” when the “hero” leaves) to “schedule-driven” in actual practice. Unlike TDD practices pioneered last decade on what at that time were classical waterfall development models where, for e.g., QA was the last in line of the critical path of the project timeline, what BDD for QA really succeeds is keeping, at least for the most part, parallel QA and DEV critical paths in each sprint.
I think at this time most of us are already aware of the following quote:
“The Systems Sciences Institute at IBM has reported that the cost to fix an error found after product release was four to five times as much as one uncovered during design, and up to 100 times more than one identified in the maintenance phase”