Chapter 1. Introduction to specification by example and Gherkin

 

This chapter covers

  • Examining why teams need specifications
  • Recognizing common specification pitfalls
  • Understanding the basics of specification by example and Gherkin
  • Solving common delivery problems with specification by example and Gherkin

How well we communicate is determined not by how well we say things, but how well we are understood.

Andy Grove

The money is all on the right [side of the product life cycle], in the area of certainty [where the product is mature]. I work on the left, with uncertainty. I’ll never be rich.

Chris Matts

Humanizing technology is perhaps the greatest challenge of software engineering. The technology industry must strive to show tremendous empathy for other people’s problems. We’re making tools for everyone out there. In the messy world of organizational politics, broken workflows, human errors, and biases, technology experts must figure out how to successfully deliver great software. It’s an important responsibility.

To do our job well, we have to

  • Make sure we deliver the right software
  • Deliver it the right way

Delivery teams are naturally competent in delivering software the right way. As an industry, we’ve developed tools, standards, and methodologies that make our designs beautiful and usable—and our code performant, secure, and easy to maintain. We keep getting better at refining and reinventing our best practices.

1.1. What’s a specification?

1.2. Why do teams need specifications?

1.3. Common specification pitfalls

1.4. Meet specification by example and Gherkin

1.5. Having conversations that identify business needs

1.6. Long-term benefits of automating conversations

1.7. Capturing conversations as executable specifications

1.8. Making software that matters

1.9. Summary

sitemap