Relishing in Perfection Part 2 -- Ingredients

Installment two of "Relishing Perfection", a series on doing BDD with Cucumber, "the right way". If you have not already, read the introduction.

Reflections

And now, some observations from having experienced BDD and Cucumber, up-close...

Feature Authoring is Iterative

Like everything else in Agile development, arriving at the "right" way to express acceptance criteria is best done organically, iteratively. There are certainly patterns to be hatched, but this is a developed capability. Expect to learn as you go and to be evolving your own Business Readable DSL.

I share a number of "low-hanging fruit" Cucumber Step "templates", in a future post.

Feature Authoring Facilitates the Requirements Conversation

Features are executable requirements. In fact, there are essentially User Stories. They are discovered, evolved and revised as such. Because Features live in the gap between the Customer and the Developer, both perspectives are required: what the Customer wants and what the Developer can deliver.

Features are Managed by the Business Analyst

We're engaged in zeroing-in on the right software solution to the business problem at hand. The traditional role that owns that quest is the Business Analyst. In a mature Behavior-Driven Development project, the Business Analyst is the perfect role to be the "Chef-in-Chief". The Business Analyst:

• develops a solid understanding of the business domain (the problem domain); so much so that she can regularly speak for the customer in their stead.
• also learns well what's possible in software (the solution domain); again to the point where she can often represent for the development team in their absence.
• seeks out, captures and develops requirements; like a sleuth, hunts down missing details; brokers the best feasible solution.
• ensures that the software developed meets not just the letter of the requirements but the spirit of the envisioned solution.

Now, in your organization, you may or may not have a title "Business Analyst" but these concerns must be managed by one or more project team members. Sometimes, the Project Manager doubles as the Business Analyst (in all but the smallest or least inventive efforts, a real mistake). Sometimes the Technical Lead also picks-up some BA responsibilities (again, this role is usually a full-time effort in itself). It's not important that there be a person with this title. It's important to have this mindset and perspective active when writing Features.

If you approach your Features as if you are the Business Analyst, you'll:

• more naturally use language that is understood by both business folks and developers; Martin Fowler describes this as Business Readable DSL.
• know how important it is to use language consistently and do so when writing stories and features;
• know when the Scenarios of a Feature are "good enough" to begin development.

All the World's a Nail...

Like with any new tool, it's easy to over-apply its use. In the case with Cucumber, especially in the context of the BDD process, it is easy to get caught up in writing a ton of Scenarios. This is requirements driving development, isn't it?!

It's true: we are developing software to serve the business, not the other way around. However, the pragmatic reality is that even with a simulated browser (OOTB, Cucumber uses Capybara) these tests take time to run... far more time than targeted unit tests/specs. Here, the principle of being test-driven meets the principle of "Don't Repeat Yourself". The balance is in enough functional tests (which is really what Features are: executable Functional Specs) to give confidence that the UI is generally working, backed by unit tests/specs that ensure the underlying components operate in the larger set of expected conditions.

When we started our project, we were purely driven by Scenario development... which is not a bad place to start. Establish those habits early. It wasn't long (the second or third feature) that our CTO (with a fresh perspective on the project) observed that we were writing a lot of Scenarios... one for each validation case. When we looked closer, we realized that we were repeating a lot of setup and clicking around just to verify that the right error message was displayed...

Be Agile: Inspect and Adapt

So, we adjusted. We realized that there was little incremental value being produced with these additional Scenarios over the "Happy Path" and one "Invalid Input" pair. The important additional cases (e.g. the whole rest of the possible flavors of invalid inputs) could easily be tested (and cheaply, both in coding and execution time) in the unit test environment (in this case, RSpec).

The key is that we made sure we were not slaves to the process. This is a core value in the Agile approach: give more credence to educated and contextualized perspective than process dogma. This is part of what it means to value individuals and interactions over process.

Next...

With that, we are ready to start pickling. There are two major skill sets to develop: authoring Features themselves and developing the code for the Cucumber Steps. They feed into each other but have their own concerns as well. In the next session, I will dive in the first of these two skills, hatching principles and practices the Business Analyst should use when authoring Features in the first place.