Knowledge is Power, but BDD only points the way

Automation to help the whole team measure and manage quality is called quality automation. This is related to “test automation,” but better because it considers the whole team and it avoids the historical accidents that interfere with business value. (I write a lot more on this topic elsewhere.)

Quality automation is important to keep the software team moving forward towards shipping a quality product; shipping at higher quality, or shipping more often, with less quality risk.

BDD is better than nothing, and it points the way towards something much better still; it shows some improvement in clarity around what the automation is doing, and better communication around the team.

I was reminded of this by a post from Andrew Knight, here.

Knight makes some points which are both good ideas and independent of BDD or Gherkin:

  1. The most effective checks strive to be small and simple
  2. Unambiguously described and reusable components make the best intermediaries between the business and how the SUT is driven
  3. The best descriptions are also business-facing (or, as Knight puts it, 3rd-person)

I’ve posted a series about BDD/Gherkin and TDD, starting here.

Briefly, using Gherkin is nearly as bad as traditional “test automation” in that it drops almost all of the quality knowledge on the floor. If knowledge is power – and MetaAutomation clearly shows what can be done with the knowledge, to ship faster and at higher quality – then BDD/Gherkin fails to deliver more than, maybe, 10% of the quality knowledge value.

Consider again where BDD is pointing the software quality profession:

  • Clarity is good on what the automation is doing to drive and measure the system under development (SUT)
  • That clarity should be accessible and trustworthy to anybody on the team

What if there were a way to get 100% of the way there?

Fortunately, there is. I call it MetaAutomation, but this is really just a pattern language to fill the quality automation problem space. It starts with the Hierarchical Steps pattern, which (unlike log statements, or anything that derives from them) supports saving all the knowledge from driving and measuring the product.

Open-source implementations of Hierarchical Steps that also support the three points above from Andrew Knight are here.

Other posts about the importance of that quality knowledge, and how to persist it are

here

and here.

No Comments

Add a Comment

Sign up here for emails with bites of wisdom on quality automation and MetaAutomation

Recent Blog Posts