THE IMPORTANCE OF WELL-DEFINED REQUIREMENTS

Last week I went with my little cousins to see a performance of “The Little Prince”, by Antoine de Saint-Exupéry. Obviously this play has nothing to do with testing, but the tester in me, who never rests, could relate the play to it.

At the beginning of the play (and the book), when the little prince meets the pilot, the former asks the latter to draw him a sheep. The pilot is not a very good drawer, so he tries to do his best:

But the little prince says it looks very sick and asks the pilot to make another:

But this one has horns and looks like a ram, so the pilot tries it again:

And this one is rejected too, because it is too old. So the tired pilot draws a box with the sheep inside (at least that’s what he says):

And that is exactly the way the little prince wanted it.

At this point maybe you have thought the same thing I thought the moment I saw it: sometimes the client is not very sure of what he wants or, if he is, he doesn’t know how to express it or he is very cryptic about it (just like the little prince). This way it is very difficult to develop and test the right application. I’m sure I’m not the only one who has faced a situation where it’s not possible to finish testing an application because the client is never happy with what he gets or what he gets is not even close to what he asked for.

And that’s why it is important to perform a requirement analysis, which encompasses the tasks that determine the needs of the stakeholders for the new application. And the testing team has to participate in this analysis, to help the client to define exactly what he wants and make sure that the developed product is the product the client asked for. To achieve this, some of the tasks of the testing team are:

• Preparation and attendance to requirements gathering meetings, in the first phases of the project
• Acquire the functional knowledge about the user needs in relation to the new application
• Revise the document that contains the requirements, in order to indicate if it describes what the client wants
• Register the requirements, which have to be validated by the client
• Define the Acceptance Test Plan, which contains the tests to be executed to check that the built application meets the requirements established by the stakeholders

To sum up, testing doesn’t start when the application is already built and ready to be tested. It starts at the beginning of the project, with the requirements definition; so that we can be sure that we know what the client needs and that we are developing the right application. This way we can draw the right picture of the sheep for the little prince from the start.

Autor | Paloma Rodríguez – Ingeniera de test