Después de haber explicado qué son las pruebas funcionales desde un punto de vista general, nos gustaría ir un poco más allá de su significado y explicar cada uno de los elementos que componen un plan de pruebas y cómo conseguir un resultado satisfactorio del proyecto.

Lo primero que buscamos en cualquier proyecto es cubrir cada uno de los requisitos del cliente, por lo que es lo primero a tener en cuenta al realizar el plan de pruebas, que recogerá todos y cada uno de los requerimientos en los distintos casos de prueba a ejecutar. Para ello es necesario hacer un análisis de toda la documentación posible: requisito, documentación funcional, manuales… así como todas las reuniones necesarias con las personas adecuadas para obtener el máximo conocimiento de la aplicación, su funcionamiento y su ámbito de negocio.

Los casos de prueba especifican los requisitos de la aplicación, por lo que cada requisito debe estar cubierto por un mínimo de un caso de prueba. Cada caso de prueba está compuesto por varios pasos a ejecutar, dependiendo de la complejidad del caso, y cada paso está compuesto por una acción, que será realizada por el tester, y un resultado esperado. Para que un caso de prueba resulte exitoso, todos los pasos deben cumplir el resultado esperado. Si uno de los pasos no lo cumple, todo el caso de prueba resultará fallido.

Al finalizar un caso de prueba su estado podrá ser:

• Pasado: si todos los pasos a ejecutar han sido correctos.
• Fallado: si uno o varios pasos han sido erróneos.
• Bloqueado: si un caso de prueba anterior bloquea las funciones de los posteriores casos de prueba.
• N/A: si un caso de prueba definido ya no aplica al haber habido cambios en la funcionalidad o requisitos.

Cuando un caso de prueba se pone en estado fallado es debido a la detección de un bug o incidencia, lo que supone que por algún motivo ha surgido un fallo en la aplicación, ya sea de software, estético o por otros motivos. Estos errores son creados en distintas herramientas con el máximo detalle del error para que el equipo de desarrollo pueda reproducirlo y corregirlo, asociándolos al caso concreto en el que ha surgido para poder tener una visión general del estado de la incidencia y del caso de prueba e indicando otros detalles útiles, como la plataforma en la que ha tenido lugar y qué tipo de bug son.

Después de que los desarrolladores o responsables del proyecto hayan solucionado los errores encontrados, crearán una versión posterior de la aplicación para seguir probando si todo ha quedado perfectamente arreglado o si estos errores pueden suponer otros distintos. Cuando el equipo de desarrollo notifica que ha solucionado la incidencia reportada, los casos de prueba asociados a ella serán ejecutados nuevamente. Esto se repetirá tantas veces como sean necesarias hasta que se confirme que la incidencia ha sido solucionada y por tanto, el resultado de la acción es el esperado, por lo que se cerrará la incidencia y se cambiará el estado del caso de prueba a pasado.

Normalmente, cuando hay varias fases en el proyecto, se crean varias releases de la aplicación, que permitirán tener un mayor control del tiempo invertido en cada una de ellas.

Durante la release final de la aplicación, se probarán todos los casos de prueba del plan y se comprobará si todas las incidencias abiertas están resueltas. De esta manera, desde Globe nos aseguramos que no se ha pasado por alto ningún detalle que pueda provocar un error en la aplicación.

Imagen: imageafter