Mark Hearon
July 28 2016

Behaviorism is a fascinating subject and an immensely powerful tool when applied correctly.  Just ask any informed educator or parent — or perhaps that coworker who appears to have it all under control — and you might discover a new, sharp arrow for your quiver of workplace magic tricks.  If you’re unfamiliar with the concept (behaviorism, that is—not magic), feel free to use your favorite dictionary app to get up to speed.  Go ahead, I’ll wait.


At the heart of behaviorism is the notion that environment has a profound effect on human behavior.  For example, one might be more likely to respond in frustration when surrounded by a group of frustrated individuals.  Similarly, when expected to code a feature, an environment of ambiguity surrounding the requirements for said feature might result in a longer-than-expected development cycle.  

Common sense and life experience tells us that both of these example scenarios are likely true, but common sense and life experience mean little (in a scientific context) because they’re both quite subjective.  The real golden kernel of behaviorism is that it provides a way for hypotheses (i.e. expected outcomes) to be more easily testable.

The Connection to User Stories and Industry Practice

Standard form for requirements-gathering, user stories are seminal for documenting and communicating the substance of a requirement in business-centric language.  However, while a user story clearly outlines what’s needed from a business point of view, it lacks a certain context.  In my experience, a user story (no matter how well it is phrased) is at best a way of documenting a business need.  However, when developing said business need, a developer may not know where to start.  Certainly, the best user stories have acceptance criteria attached, but I’m referring to something even more granular—behavioral characteristics leading to a more well-defined functional test. 

An Analogy

Providing a user story (without a behavior-driven test scenario) to a developer with the expectation that a beautifully-crafted word processor will result could be compared to giving a wet newspaper to an origami artist with the expectation that a swan figurine will result.  If you’re thinking, “Well, the artist could make the best of the situation and use papier-mâché to craft the swan” you are to be commended for thinking creatively.  However, if the original requirement was for an origami swan, a papier-mâché swan won’t fit the bill.  What’s the point?

The fewer the expectations and the more open-ended the ask, the greater the likelihood for unmet expectations, deviations from previously agreed-upon standards, and ultimately, an unhappy client.  

Therefore, utilizing behavior-driven development principles which clearly delineate the intended function of a feature helps to close an additional (potential) gap in the development cycle.  The end result might be fewer iterations, fewer wasted resources, a greater sense of accomplishment on the part of the team (i.e. a morale boost), and a cost savings to the client.


Behavior-driven development, Cucumber syntax, Gherkin, etc. are not substitutes for any of the following:

  • Inter-departmental collaboration

  • Requirements elicitation/gathering/trawling

  • User stories

  • Scrum

  • Any industry “best practice”

However, when added to an existing, healthy development framework and testing practice, behavior-driven development (BDD) can prove an excellent augmentation.


Given a need for greater functional clarity

When behavior-driven development principles are applied

Then your practice might just take a turn for the better



  1. Does your firm use BDD to augment the traditional user story/requirements-gathering framework?

  2. How has incorporating BDD helped improve your personal (or firm’s) practice?

  3. Why might BDD better facilitate an automated testing framework?


About the Author

Mark Hearon image

Mark Hearon is an accomplished, ISTQB certified, and award-recognized QA consultant.  Methodical and skilled in marrying the software development lifecycle with the testing lifecycle, Mark has a proven track record of success in full-spectrum test management for AVIO's clients.  Mark has championed testing best practices in all phases of product development from planning and discovery through deployment and test closure.  Focused on team growth and measurable results, Mark stands ready to mak

Join the Conversation

Enter your first name. It will only be used to display with your comment.
Enter your email. This will be used to validate you as a real user but will NOT be displayed with the comment.