Recently, we had a really interesting conversation regarding the differences between BDD and BDA Is Cycle “doing BDD”? and discussed where Cycle fits into that equation.
BDD on the other hand has its purpose but it’s not automation. It’s a development practice. But it turns out that behavior in prose can be used to drive automation.
Ok got it - so BDD is a practice that may or may not involve automation. It’s really about alignment, collaboration, and requirements discovery. And that’s great. But, the challenge I have, is that the need to realign, to discover new requirements, to readjust and make changes to the system under test never stops. So, in the truest sense of BDD (and I’m talking about the purists’ view out there) is BDD impossible to achieve once an application has been deployed for the first time? Or can we back into it?
At Cycle, we often engage with a customer when they have a need to introduce automation to solve ongoing issues - almost always after the solution has been in production for sometime. We aren’t afforded the luxury of starting at the beginning with them but we do have an opportunity to improve quality by conducting BDD-like ceremonies, producing meaningful and valuable Feature files that realign the team, help discover miscommunications and missed requirements. And ok, since we aren’t starting before the solution was deployed maybe this isn’t BDD in the purist sense – maybe like @branko points out it’s really BDA.
It seems like the question at hand isn’t how you’re approaching the construction of the Feature files and automation but simply a question of when you did it. So can the ceremonies be the same but BDA not be BDD because you are starting after the fact? It’s an interesting question.
At Cycle, what we are seeing is that we can often prove the value of behavior-driven testing strategies (call it BDD or BDA) by coming in after the fact, producing meaningful Features and eventually working our way left (shifting-left) such that new changes are actually pushed through a more traditional BDD process BEFORE production. But we did’t start that way ---- we needed to prove the value first.
So can BDA actually become BDD? Is BDA a gateway to BDD or can you never get there once an application has been deployed? If new changes are introduced by using BDD but the original Feature files were built using BDA – where do those two concepts come into alignment? It seems like @magowan has some practical experience doing this with our largest customers and I would love this thoughts.
And all of that aside, I think we often get so hung up on the concept of “is it BDD or not” that we overlook the amount of organizational change management required to actually meaningfully change how these large organizations work. Moving to a purist version of BDD practices/ceremonies is not a small feat. At a smaller organization or startup maybe we can get everyone around the idea and start that way. But in large enterprise organizations, it really takes a massive change and organizational commitment from the financial stakeholders, the project managers, the business analysts, the systems analysts/developers and the QA team to make that shift happen. And to make a change like that is expensive in terms of resources when an organization may not necessarily buy into the value of that change. Change after all, is uncomfortable.
I see a ton of back and forth online regarding whether something is BDD or not. But I don’t see a lot of discussion about the incredible amount of organizational change it takes to shift how these organizations work. Why is that?
Are we too hung up on when something starts and what it is to focus on what it takes to actually achieve the benefits?