bdd

Quality, Specification by Example

I have been using Specification by Example (a.k.a BDD, ATDD) for the last couple of years. This has helped bridge the gap between technical people and business people. It has also helped ramp up new members on our team, since we have a living documentation of the system. This isn’t always easy and we’re continuously looking for ways of improving the structure of our BDD specification files.  There are some questions that help us spot improvement points:

  • How easy is to have an overview of what the product does?
  • What are the main business areas of the product?
  • How easy is to find a specification?
  • How easy is to find related specifications?
  • How does this feature relate to that feature?
  • If you just point a new joiner to the specifications folder, will she have a decent idea of what the system does?

In this blog post I hope to give you a few tips that might help answer some of these questions. These aren’t new ideas, but I find them pretty effective. Continue Reading

Quality

If you ask a hundred developers to define software quality, you’ll probably get a hundred different answers. There are a lot of ways to categorize quality, but one that I find most useful is building the right product and building the product right.

Building the Right Product

First we have to make sure we are building the right product. The most performant and secure product, having the cleanest and most extensible architecture, covered with unit tests and acceptance tests is in vain if nobody uses it.

In their book, Lean Software Development: An Agile Toolkit, Mary and Tom Poppendieck define this dimension of quality as the perceived integrity of a product. Perceived (external) integrity means the totality of the product achieves a balance of function, usability, reliability, and economy that delights customers.

Traditionally, when customers want to build a product, they talk with business analysts and write down the requirements. These documents are then handed over to architects, who then define the high level architecture and pass the design documents down to programmers who start implementing. There’s a gap between each step and as we go through the process, we lose more and more information and our chances of building the right product get slimmer.

Continue Reading

Books

Writing good tests is hard. Writing good specification is even harder. On my current project we treat test code with the same care we treat production code (which should be the norm on all projects), but we could still improve the readability, reliability and maintainability of our test suite.

With this in mind, Fifty Quick Ideas to Improve Your Tests by Gojko Adzic, David Evans and Tom Roden was the perfect choice for our book reading club. I’ve previously read Gojko’s Specification by Example, which really helped me better understand BDD and how to use it in practice, so I had high hopes for this book.

50 quick ideas to improve your tests

Continue Reading