Recientemente, en una reunión, un compañero afirmaba rotundamente que un requerimiento no necesita ser analizado para ver si se puede testear, es decir, si es “testeable”. Afirmaba lo siguiente: “Si el cliente pide ese requisito, se puede y se debe testear…no es necesario analizar nada, lo quiere el cliente y punto”. Desde mi punto de vista era una afirmación un poco arriesgada. Esto me hizo pensar, ¿realmente sabemos que quiere decir que un requisito sea “testeable”? Un requerimiento testeable nos asegura que podremos ejecutar nuestras baterías de pruebas llegado el momento de ejecución. Probablemente para un analista de negocio (Business Analysis) no sea un asunto demasiado importante, pero para los equipos de testing si que es un factor crítico a considerar. En principio, todo requerimiento debe poder ser testeado, pero en la práctica la cosa es diferente.
Por tanto los equipos de testing deberíamos de tener este atributo siempre en cuenta cuando nos encontremos en las fases de toma de requisitos y análisis. Ya sabéis que cuanto antes nos demos cuenta de la “testeabilidad” de un requisito, antes podremos mitigar el riesgo y gastaremos menos dinero. Por ejemplo, tenemos un nuevo producto y debemos comunicarnos con uno de nuestros clientes. ¿Es este requisito testeable? ¿Podemos comunicarnos con nuestro cliente para enviarle y recibir información o debemos simularlo? Si tenemos que hacer una simulación implicará que tendremos que crear todo este set de pruebas simuladas y tal vez necesitemos ayuda de desarrollo. ¿Está nuestra arquitectura preparada para realizar estas pruebas? Tal vez en el entorno en el que queremos realizar las pruebas no tenemos todos lo elementos necesarios para hacer una cobertura total. Esto implicará la comunicación con el equipo de arquitectura para ver cómo podemos mitigar este riego. Esto son sólo algunos ejemplos, pero podemos encontrarnos en miles de situaciones similares…así que no deis por hecho la testeabilidad en la práctica de un requisito teórico.
Es cierto que no podemos ignorar las demandas de nuestros clientes sólo porque un requerimiento es difícil de testar, pero sí que debemos comprobar que el producto cumple con ellos.
Desde mi punto de vista todo requerimiento tiene que ser testeado. Puede que a distintos niveles, ya sea con dummies o fakes, e incluso se puede hacer un agreement con el cliente para acordar las pruebas que se haran (en casos extremos).
Pero sea como sea, todo requerimiento se tiene que testear, y quien diga lo contrario, es que no tiene suficiente experiencia testeando (sin animo de ofender).
Saludos desde las Vegas! Aqui las tragaperras no tienen bugs
Entiendo que todos los requisitos de un sistema deberían poder probarse de alguna forma. Si no, no creo que sea un requisito.
Ahora bien, es posible que no sea verificable en el entorno de un proyecto (tiempo, coste, entorno…) y ser validable por el cliente o por el contratista una vez que el sistema está en operación o en el entorno de operación.
Por ejemplo, el requisito de Kennedy de ‘ … antes de que finalice la década (los 60) un americano pisará la luna’ solo se puede validar.