The service provided by Consileon was professional and comprehensive with a very good understanding of our needs and constrains.

Wolfgang Hafenmayer, Managing partner, LGT Venture Philanthropy

Technical quality of staff offered, capability of performing various project roles, as well as motivation and dedication to the project (... [...]

dr Walter Benzing, Head of development B2O, net mobile AG

Technical quality of staff offered, capability of performing roles of developers, lead developers, trainers, team leaders, architects as wel [...]

Karl Lohmann, Itellium Systems & Services GmbH

Firma Consileon Polska jest niezawodnym i godnym zaufania partnerem w biznesie, realizującym usługi z należytą starannością (...)

Waldemar Ściesiek, Dyrektor zarządzający IT, Polski Bank

The team was always highly motivated and professional in every aspect to perform on critical needs of our startup environment.

Denis Benic, Founder of Ink Labs

Who needs requirements?

Category: Testing Tags:

Who needs requirements?


The upside down text

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


Stranger things upside down model

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?


upside down requirements model

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!

Patryk Oleksyk

Test Lead, IT consultant.

Patryk is the Company's first tester. An agile testing enthusiast who finds fun and passion in exploratory testing and checkers automation. Tries to be an advocate for clients and testing. In free time he plays indie video games or can be found working out.



Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Trwa ładowanie