En cualquier método de producción sea del ámbito que sea, son necesarios los controles de calidad ya que garantizan que el producto presente unas determinadas características preestablecidas, cumpliendo además con el fin al que está destinado. Esta idea anterior muy generalista se aplica al campo del desarrollo software, y más concretamente al desarrollo del software libre gvSIG Desktop, siendo esos controles de calidad los planes de prueba.

Un plan de prueba es un documento escrito que aúna los casos de prueba necesarios para evaluar cualquier desarrollo software. Un caso de prueba no es más que un breve documento que describe de manera detallada el comportamiento de parte o la totalidad de una herramienta del software al realizar una determinada acción concreta.

Para llevar a cabo un caso de prueba se tiene que describir una simulación útil, fijando las condiciones al igual que los datos utilizados, de modo que solo se teste el “motor” o algoritmo que trata dichos datos bajo dichas condiciones. De lo anterior se puede deducir que la función principal de un caso de prueba es poder detectar errores de manera fácil y sin apenas consumir tiempo/esfuerzo cada vez que se realizan cambios en el código del software.

Además, como es lógico, si un desarrollo pasa todos los casos de prueba y por tanto el plan sin fallos o errores, este sería correcto.

Las partes de un caso de prueba son:

1. Título. Este compuesto por un identificador único más una breve frase de describe que se va a probar.
2. Enlace de petición existente con ese caso. Enlace a la web de control de errores de gvSIG con el identificador único de forma que se puede comprobar si ya hay algún reporte de error asociado al caso en cuestión.
3. Descripción. Breve texto que resume la acción a realizar, así como el tipo de resultados obtenidos. La descripción debe identificar sin ningún tipo de duda el comportamiento a testear.
4. Prerrequisitos. Lista con los datos y configuración necesarios para la correcta ejecución del caso práctico.
5. Pasos. Secuencia de acciones a realizar que proporcionan una serie de resultados tanto intermedios como finales. Esta es la parte más importante del documento ya que en ella se detallan todos los aspectos a probar y la forma de hacerlo.
6. Resultados esperados. Texto en el que se indican tanto los resultados intermedios si son necesarios, como los resultados finales del caso. Puede presentarse como un párrafo o en forma de lista si los resultados son varios o así se mejora la comprensión.
7. Reportar fallo. Parte del documento en el que se facilita la comunicación de errores detectados tras realizar el caso de prueba. Se compone de dos enlaces, un primer enlace que te dirige a la página web de control de errores de gvSIG y un segundo enlace, que previo a identificación te permite reportar en la página anterior una petición de corrección de error de dicho caso mediante su identificador único y titulo de manera automática.

Una vez definidos y detallada su estructura se muestran una serie de recomendaciones a tener en cuenta para la correcta elaboración de un caso de prueba.

• Cuidar la ortografía en todo el documento.
• Garantizar la comprensión de todo el texto. Prestar especial atención a la descripción ya que esta debe describir inequívocamente lo que se va a realizar.
• El Título debe estar compuesto por el identificador único y un breve resumen de la descripción.
• El apartado Pasos debe de detallar sin ningún tipo de dudas la acción a realizar por simple que sea.
• En el apartado Pasos no se debe obviar ningún paso intermedio por simple que sea.
• En el apartado de Resultados esperados se puede detallar el resultado en un párrafo o en forma de lista si hay resultados intermedios. La elección del formato depende de que caso hace más comprensible el resultado final.
• Se permite el uso de imágenes en los apartados Pasos y Resultados esperados, pero si se puede describir en texto mejor.

En conclusión, los casos de prueba son elemento necesario en un ambiente de desarrollo software ya que garantizan que los productos presenten resultados correctos, cumpliendo una serie de requisitos. Siendo la implantación de estos una forma de aportar más calidad y profesionalidad al software.

 Referencias:

Protocolo para la elaboración de casos de prueba.

Artículo escrito por José Olivas Carriquí