Last week my group and I were discussing behavior-driven development. It is a type of development that refines our previously learned developments. This is a great jumping point to what we were previously learning and it will make for a great assignment. I would like to give more information on this subject matter because it is valuable. This is another practice that is used in the field that can be used in the future.
Behavior Driven Development (BDD) is an agile testing practice that prioritizes creating automated tests first before specifying system behavior. BDD is utilized in a group setting where both agile teams and business participants can see eye to eye. BDD are tests used to capture a story, feature, or capability from a user’s perspective. During this development, there should be three different heads of mentality to considered. Customer minds usually stakeholders understand the business needs and their desire for new requirements. Developers understand what needs to be done to accomplish their responsibilities and technological feasibility. Test-centric minds should consider any exceptions, new edges, and boundary conditions. There are three phases during BDD discovery, formulation, and automation. The product owner or product manager creates criteria that must be used to write a good story. Then, the discovery process where the team finds any additional information that could enhance the criteria. There is an automation phase that automates the acceptance test. This test shares a lot of similarities with Acceptance Test–Driven Development (ATDD) and Specification by Example (SBE).
This new development strategy was very useful to learn. It’s good to understand different types of development plans and how you can combine them to make a stronger development cycle. During the agile team cycle, I feel like every cycle you can change what type of software development you use for that cycle. Based on the project, resources, and time you can choose different software developments. Learning about BDD gave me an insight into the business side of the development process. These are things you may not think about when creating your software but should be a priority. You would expect your software project to be examined by someone who is informed in the field but to try to explain to someone that is funding it would be a hassle but necessary. It makes sense that people who aren’t on the team would have to understand the development. It’s a group effort between multiple teams that all must work in unison to create a working product.
From the blog CS@Worcester – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.