Ios

Emilio Mayoral

 

Mucha es la documentación que en un proyecto es necesaria. A continuación os trasmito mi opinión personal sobre uno de estos documentos que se está quedando en desuso y que me parece es de gran importancia en el ciclo de desarrollo del software. Os hablo del plan de pruebas.

La finalidad del plan de pruebas es básicamente, la detección de errores a todos los niveles. Este documento debe de empezar a generarse al inicio del proyecto e irse incrementando durante el desarrollo del mismo, ya que es vital que estos errores se detecten cuanto antes para que el coste de la corrección de los mismos sea el menor posible.

¿Por qué está desapareciendo?

 

Todos nos hemos dado cuenta que en la actualidad, a la velocidad en la que nos vemos inmersos a la hora de desarrollar nuestro trabajo de consultoría, la documentación ha pasado al plano de lo estrictamente necesario. Un análisis funcional, un orgánico (que por funcionalidad se ha embebido por el anterior) y un cuaderno de carga por cada módulo independiente que desarrollamos, es lo que más nos estamos encontrando. Pero, ¿y un plan de pruebas?, qué ha pasado, ¿por qué ha dejado de utilizarse?

Realmente, hay que reconocer, que es un documento muy laborioso que implica la participación:

• De los funcionales, para definir los resultados los distintos módulos del proyecto y la interconexión entre ellos.
• De los técnicos, que deben de definir el resultado de cada uno de los programas que desarrollan.
• De los jefes de proyecto, que definirán los recursos, calendarios, hitos, planes de contingencia,etc.
• Usuarios, que deben dar el visto bueno a los resultados obtenidos.

 Y que además, el plan de pruebas, es un documento que estará vivo hasta el final del proyecto, por no olvidar que puede llegar a niveles de ingeniería, a mediciones de rendimiento, pruebas de estrés, de estabilidad, etc.

Tenemos que tener en cuenta, que el plan pruebas no se puede considerar un simple documento, si no que sirve de estabilizador del proyecto, al ser el nexo entre la toma de requerimientos y el producto final y que obliga a la participación de todos los miembros del equipo de proyecto, incluido por supuesto, el usuario final.

Este último punto es muy importante ya que supone la participación activa y comprometida del usuario final y obliga al cliente a aceptar, o mejor dicho, participar, en las pruebas realizadas al producto desarrollado. Esto puede ser algo tedioso ya que dependemos de la aptitud y compromiso de usuarios que en múltiples ocasiones nos pondrán pegas y provocarán mayor esfuerzo del que esperábamos, pero nos asegura que a la larga nos dará la tranquilidad necesaria para ir avanzado a siguientes hitos del proyecto sin dejar casos pendientes que nos vayan retrasando cada vez que debamos retomarlos.

Para resumir sólo identificar algunos (no todos), de los beneficios de la realización de un buen plan de pruebas:

• División de programas en módulos analizables individualmente.
• Implicación de todo el equipo en el proyecto
• Detección de errores a tiempo.
• Detección de problemáticas no tenidas en cuenta en el análisis inicial.
• Integración del usuario mediante compromisos de aceptación. 

Un saludo