Who needs requirements?

Who needs requirements?

Requirements… Requirements… Requirements… One of the few things that every development process could not live without. No matter what methodology, tools or roles you have in your team, you will have to work with them. Even if one dislikes them, they are still the necessary tool for communication between a stakeholder and a development team.

Their shape and content differ from project to project as there is a lot of pressure from people who gather, document and update them. In the perfect world, requirements could be a hell of a source of knowledge, as they contain information about design, implementation, test ideas or areas of the software being affected by changes (and even much more), but unfortunately, the reality is different.

Nevertheless, in the world of quality, verification of new features based on requirements alone is not enough.

A thing about requirements

If your role as a tester is only to check if the requirements are ok and nothing else you are missing the point of testing.

Testing is about exploring the product, learning about it, evaluating and validating it (and so much more). To do that you need much more than only requirements. 

To show you that the requirements are not enough, I want to present to you a model I use when I talk about requirements with the team or a client. 

An acrobat and a flea

In the show Stranger things (no major spoilers ahead) there is a concept of a parallel world called by our protagonists “Upside down”. That world is similar to ours, but inhospitable and run by monsters. To move the story forward, there is an exposition about a concept of “acrobat and the flea”.

Think of it this way, acrobat is moving on a tightrope. The rope symbolizes our world that is depending on the laws of physics. Because of these laws, the acrobat can only walk forward or backwards. On the other hand, we have also flea on the rope. It can move in the same direction as the acrobat. There is a catch, the flea can also move on the side of the rope or underneath it. Thanks to that, it can move to the „Upside down” world with ease. 

What it has to do with requirements?

Now let’s change labels in the model a little bit. Let’s think about Acrobat as our client/stakeholder who is responsible for creating the requirements for the product in the first place. Their world would be only the world of requirements. They can only move in only 2 directions on a tightrope which is our product under tests.

But what they don’t know or are not aware of, is the fact that they cannot see the whole picture. With all the requirements they create, they also produce additional conditions which are invisible to them. That’s why they need the flea which will be their guide to this other world. The flea could be anyone who can critically think about the software. This could be a tester, a developer or anyone responsible for quality in the project. That person needs to move between the two worlds to share the whole story about the “real” requirements.

The outcome?

Next time if your role is to check already written requirements.

1. Please look and explore beyond them – do not be biased towards them
2. Please break them down – something could be “lost in translation” 
3. Please learn more about them – use critical thinking and healthy scepticism
4. Please check the invisible (unwritten) ones – be a flea!