I’ve just finished reading Specification by Example, a new book (currently in MEAP) by Gojko Adzic. Highly recommend to anyone involved in software creation (developers, testers, product owners, product managers, …). The book includes great insights into building the ‘right thing’ and the ‘thing right’, drawing on experiences from many successful software projects and teams. These projects each have dedicated chapters providing real insight into how these teams work and the steps they took to get there.
But you don’t have to trust my vague recommendations, I’ve included a few key examples from the book below:
Like cheap wine, long paper documentation ages rapidly and leaves you with a bad headache if you try to use it a year after it was created.
Working from the outputs ensures that there is always something that the business users can provide feedback on.
Understanding why something is needed, and who needs it, is crucial to evaluating a suggested solution.
Solve technical difficulties in the automation layer. Do not try to solve them in the test specifications.
We automate specifications to get fast feedback, but our primary goal should create executable specifications that are easily accessible and human-readable…
When each team worked to deliver a whole feature end to end, it was much easier for business users to collaborate with the team to specify the conditions of satisfaction and engage in illustrating them with examples.
The biggest benefit from this is getting us to talk together so that we have a mutual understanding of the requirements. That’s more important than test automation.
Long term value comes from living documentation
The first chapter is free to get you started.