Tuesday, September 21, 2010

Behavior Driven Development

College was misleading.  There, we were led to believe that the customer (professor) was technical and actually knew in advance exactly what they wanted.  The requirements were chiseled in stone, two months out, and there were test suites waiting to tell us if our work was "correct."  

In reality, the customer is generally an expert at something other than technology.  They generally don't think in terms of edge cases and they certainly don't write tests for us in advance to ensure that we cover them.  Even if they were, business is a fast-paced and evolving thing, what is seen to be a competitive advantage today may be a liability tomorrow.  The only constant is change.

Agile teams understand this and structure their approach to delivery with this in mind.  Rather than attempt to conceive, build, and deliver the perfect application in one fell swoop, they steadily deliver work in small, usable chunks, every few weeks.  The customer is encouraged to think in terms of what functionality will deliver the maximum benefit to the business and prioritize the pipeline of work accordingly.

This tends to reduce feature creep, but it doesn't address the generally poor communication between the project's various stakeholders and the resultantly poor-quality deliverable:

This is where BDD comes in.  It bakes quality into the process by smoothing communication between stakeholders.  Here is how we're practicing it on my current project:
  • The Business Analyst works with the Customer to determine what it is that the business is trying to accomplish.
  • The BA, QA, and Developer sit down and have a discussion. The QA focuses on flushing out the bounds of the system and edge cases.  The Dev focuses on implementation and brings up potential technical hurdles.  The Business Analyst answers questions, ensuring that the customer's high-level business needs are met.  This is the software equivalent of 'measure twice, cut once.'  Many times, poorly conceived requirements are eliminated before even reaching development  
The outcome of this meeting is a document that will function as a specification, test suite, and living system documentation. Here is a simple Login Story written in Given, When, Then format:

Login Story

Scenario:  Basic Login
Given I am a basic user
When I login
Then I should see the basic homepage

Scenario:  Administrative Login
Given I am an administrative user
When I login
Then I should see the administrative homepage

Scenario:  Invalid Login
Given I am not a valid user
When I login
Then I should see the error page

  • The developer(s) now get to work on the implementation of the story.  The preceding conversation will have given them a high-level understanding of what the business wants from the system as well as clearly codified acceptance criteria.  Their high-level perspective prevents them from diving down a tangential rabbit-hole while the non-prescriptive nature of the spec provides for creative latitude in implementation.
  • The feature complete, the QA and Developer pair on functional test implementation.  The developer brings technical expertise, while the QA brings an understanding of the system as a whole.  They "fix", to each step in their story, code that will exercise the new system features.
  • Next comes what we call the "desk check." The pair calls the BA over and demonstrates the completed feature by running the functional test.  The BA may give an initial sign-off there or they may notice something incorrect  or incomplete.  In the case of the former, the dev will move on to a new story; in the latter, the dev will correct the behavior of the system, update the functional test to "lock-in" the additional requirement, and re-submit for approval.  This process has the benefit that the developer has not yet mentally context-switched to a different piece of work and so they will be able to more quickly rectify the problem than if they worked on the fix weeks later after it gets logged as a bug.
  • When, at some later date, the business inevitably decides to change a system requirement, the test will fail, as the system is no longer performing as expected.  The story is then modified to reflect the new behavior.  Using our previous example:
Scenario:  Invalid Login
Given I am not a valid user
When I login
Then I should see the error page

Scenario:  Invalid Login
Given I am not a valid user
When I login
Then I should see an error message on the login page

In this way, we say that the story functions as a living document.  As the behavior of the system evolves over time, the team is forced to evolve the documentation in parallel.

No comments:

Post a Comment