People behave, so … behavior over feature
In software development, we often talk about specifications. But not all specs are the same. Some describe features, while others describe behaviors.
This post starts from an observation on how specs are circulated inside organizations, and later outside.. Users, people, behave, they to not “feature”, they just string actions towards a goal. These actions, when repeated around similar contexts, they build behaviors, that change with context.
Feature-based specifications focus on what the system should have. For example, “The app must have a login screen.” These specs list things the software should include. They are inward focused, looking at the app/system as focus point. This approach has a ton of assumptions, more or less transparent, more or less obvious.
Behavior-based specifications focus on what the system should do. For example, “When a user enters the correct password, they should be logged in.” These specs describe how the system reacts to actions. The behavior based spec is anchored in the user’s perspective.
So, what’s the difference? Features are about things. Behaviors are about actions.
Many teams now prefer behavior-based specs. This approach is called Specification by Example or Behavior-Driven Development (BDD).
Here are four advantages of behavior-based specs:
- Clear communication: Everyone—developers, testers, and business people—can understand them.
- Better software testing: Behaviors can be turned into automated tests.
- Fewer bugs: Teams catch problems early by checking expected behaviors.
- Real examples: Specs use real-life situations, which helps everyone know what to expect.
A case study at Anaplan showed that using behavior specs helped catch over 200 bugs before release. That’s a big win!
In short, writing specs as behaviors helps teams build better software, faster. It keeps everyone on the same page and makes sure the software works the way users expect.
To me, as a tester at heart, I also tend to describe defects more from a behaviour perspective, and less from a feature side. I know, there is an old joke, that a bug is actually a feature in disguise, and if this joke does not work for behaviors, it is then one more argument.