An important aspect of handling risk is having the requirements of what is being built clear. The more unknowns you have, the more riskier it becomes not just in the end-product, but also during product development. Let’s look at how this can be handled from a Software Testing perspective, a way for digging out requirements.
It has almost become a pride to not to have requirements, thanks to misunderstanding Agile manifesto, because requirements is mistakenly projected as a 150-page documentation, in fact as a propaganda. This, in itself, is false. Requirements can be clear, precise, and be as crisp as possible addressing the salient points. It could even be an Excel sheet for quick discussions with a whole team approach.
Talks are being given on how to test without requirements. Well, no one is going to ‘test’ without requirements, because testing by nature is about verification and validation against expectations. It is not that we are trying to test without requirements, but maybe we are starting out the testing process without requirements. And that’s okay, because, there are situations where the client wouldn’t have provided the requirements, or, in case of startups building a B2C product, we won’t know what the end-users will like and it has got to be iterative.
The process of learning about what we are trying to build is important. This is where questioning for learning comes in. An effective questioning process to learn all that is possible about the contours of the product that we are building is the key, and there can not be a standard format for what questions to ask and when, because it is highly context-sensitive. By becoming capable to work effectively with product owners and business analysts and learning how to question effectively to bring out the requirements is a skill that has to be acquired by experience.
It would be incorrect to glorify not having requirements in all instances. We should try our best to get the requirements specified as far as possible. In spite of all our efforts, if we are not able to get the requirements, then we engage and start asking questions. Even in situations where requirements are available, reviews are done to find out gaps.
To summarize, what can a Software Tester do? Your only goal should be to find out about how the product should behave. And to me, the only way to do that is to engage with the product owners, developers, and business analysts, and work along with them in digging out requirements as clearly as possible.
If you need help for your organisation in how to figure out the requirements, feel free to get in touch with me.