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:

princ1

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

princ2

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

princ3

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):

princ4

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.

 

Para más información:

 Paloma_Rodríguez

Paloma Rodríguez – Ingeniero de Test – Sogeti España

 paloma.rodriguez@sogeti.com

Autor: qanewsblog

Sogeti es una compañía tecnológica perteneciente al Grupo Capgemini y especialista en: Testing y Calidad de Software; Soluciones Microsoft y High Tech Consulting. En Sogeti entendemos la importancia de obtener el máximo valor empresarial de sus sistemas de IT, por ello somos líderes mundiales en Testing & QA. Somos creadores de las metodologías estándar del mercado: TMap® (Test Management Approach) y TPI® (Test Process Improvement). ¡Nuestro compromiso es el Testing!

Deja tu comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s