Q&A w/ Robin Goldsmith on Requirements-Based Testing
Earlier this quarter, we hosted a webinar on Agile testing requirements with requirements and testing expert Robin Goldsmith. The webinar, titled Not Your Grandfather’s Requirements-Based Testing: Do Agile User Stories or ATDD Fix It?, generated a lot of interest and questions. Here, Robin answers a question from one of our viewers.
Q: If requirements should include more detail, what do you recommend to get more detail in a user story? More contact with the business users? In an Agile environment, that can be a challenge. Many times, the business users are swamped doing their own job as well as serving as SMEs for the development team, so it’s hard to get much participation.
A: Getting more real business requirements detail in an Agile environment has two key aspects: 1) discovering the detail and 2) capturing it. One cannot base tests effectively against unidentifiable requirements.
Rather than adding detail to a given story, additional detail generally would be provided by defining user story acceptance criteria/tests and by adding user stories, such as what happens during grooming and when epics are broken down into component user stories. These become the common formats used for capturing real business requirements in Agile.
In turn, discovering these real business requirements tends to occur at four points in an Agile environment:
- Writing user stories initially
- Grooming and refining/revising the user stories in the backlog
- Defining user story acceptance criteria/tests
- Conversations about the user stories being implemented in a sprint
In my view, Agile’s main requirements-detailing activity is conversations, which also is its biggest requirements trap. Conversations of this nature usually occur by the coffee machine or in the break room. Unfortunately, these conversations are a trap because their findings are seldom captured in any reliable manner and because developers typically are not very good at discovering actual business requirements. Too often, neither are product owners nor business analysts.
Therefore, to systematically improve requirements completeness and accuracy, try to focus on the first three items listed above and, perhaps, the conversations by the coffee machine will become less important.