At a recent SoCraTes Day the test sessions were often focused on how to derive good tests. Yes, I was part of that as well.
At the discussions of one book1 the presenter told an anecdote about their way to derive tests. They brought the product owner, the developer and the tester into one room. They discussed missed tests, acceptance tests, the unstated features and behaviours and probably many more things.
Other participants mentioned similar happenings, e.g., discussing behaviour and acceptance testing with the customer after the fact: “we expected him to say yes to our acceptance tests”.
It otherwise derailed the conversation, but one attendant mentioned correctly that deriving test cases is a very mechanistic procedure. Equivalence class partitioning and boundary value analysis is a good starting point. She failed to mention though that this requires complete and correct requirements. It later dawned upon me: this isn’t about tests — it’s requirements engineering with extra steps. Putting the cart before the horse by extracting requirements after the implementation is done.
In the tradition of TDD I’m tempted to call this TDRE: test-driven requirements engineering. There’s even a paper2 that elaborates on the process.
We have to expect that requirements change and, unless you’re on a safety critical project, e.g. following any EN 61508 derived standard, to be incomplete. We’ll have to find processes to work with these inconvenient facts of life. Elevating a crutch that fixes gaps in the specifications to best practices is some shape of reckless.