A Tester’s Role in Requirements Exploration
Shared understanding of desired and undesired behaviors for each new product feature is key to delivering value to the business frequently and predictably. If testers, programmers, and the business each have their own view of what the final feature should look like, everyone is disappointed.
Sadly, this problem has been happening in product delivery for too long. This cartoon, originally published in 1973, captures the concept wonderfully; more process does not help.
Agile is supposed to solve that problem by getting people to talk to each other in real time. However, many teams still lack a shared understanding of what they are going to build, even as they start coding.
As testers, we can explore feature specifications early, contributing to successful and timely delivery. In phased and gated projects, we could do that by reading and challenging what was written. However, there is limited documentation in agile teams, so testers need to use their critical thinking skills in different ways.
With a testing mindset, testers can ask questions—as many questions as it takes so the team feels confident that they have a shared understanding. Use pictures to draw. Elicit examples from the product owner or other stakeholders. Those examples can then be used as test scenarios that guide development.
Examples of expected behaviors (happy path) and misbehaviors (spawning from the “what if” questions) will become high-level acceptance tests to show the intent of the story. They turn into the requirements that define scope and intent.
The tester’s role doesn’t go away; it changes and expands. It is not only about finding defects or breaking illusions about the product—it is about helping to prevent the defects in the first place or finding them early enough in the process to reduce risk caused by misunderstandings.
In July, Alex Schladebeck asked a question on Twitter: “How do you know you’re a (good) exploratory tester?” There were lots of great answers, and this was mine: “When I am looking at a story and start to ‘see’ different paths and possible consequences, I want to explore more to see if we even understand the problem.”
To me, that is all about exploring requirements.