PLAN DE PRUEBAS

La planificación de las pruebas es uno de los puntos más importantes a la hora de probar un
proyecto, tenemos que tener controlados todos los aspectos, desde la manera de la que vamos a probar,
cómo lo vamos a probar, los recursos de los que vamos a disponer, las pruebas de regresión , la
documentación del proyecto, etc.
Hay varias maneras de realizar un plan de pruebas. Una de ellas es aplicar la norma “ISO/IEC
29119 Software testing” que sustituye a la norma “IEEE 829” y que define como tiene que ser la
estructura del plan de prueba. En esta norma se indican los puntos que tiene que tener un plan de
prueba [WEB19]:
• Identificador del plan de pruebas.
• Introducción.
• Elementos de la prueba.
• Características a probar y no probar.
• Método/enfoque de prueba (implementación de la estrategia de
• prueba).
• Criterios de paso/fallo de la prueba.
• Criterios de entrada, salida, suspensión y reanudación de las
• pruebas.
• Entregables de las pruebas.
• Tareas/hitos clave de las pruebas.
• Cronograma.
• Necesidades del entorno.
• Responsabilidades.
• Dotación de personal y necesidades de capacitación.
• Riesgos.
• Aprobaciones.
La planificación de las pruebas es uno de los principales puntos a la hora de probar el software
con éxito. En ausencia de un buen test plan es muy poco probable que las pruebas se ejecuten en
un plazo estipulado e incluso se incrementara el costo del proyecto al consumir más tiempo y
recursos. Esta planificación tiene que estar incluida dentro de la planificación general de un proyecto de
software.
 EJECUCIÓN Y ANÁLISIS
Implementación y Ejecución de Pruebas
la ejecución de pruebas debe iniciar con la creación de los datos de prueba necesarios para
ejecutar los casos de prueba diseñados. La ejecución de estos casos, puede realizarse de manera manual
o automatizada; en cualquiera de los casos, cuando se detecte un fallo en el sistema, este debe ser
documentado y registrado en una herramienta que permita gestionar los defectos (Bug Tracker). Una
vez el defecto ha sido corregido por la firma desarrolladora en su respectivo proceso de depuración, es
necesario realizar un re-test que permita confirmar que el defecto fue solucionado de manera exitosa.
Por último, es indispensable ejecutar un ciclo de regresión que nos permita garantizar, que los defectos
corregidos en el proceso de depuración de la firma, no hayan desencadenado otros tipos de defectos en
el sistema.
Evaluación de Criterios de Salida
los criterios de salida son necesarios para determinar si es posible dar por finalizado un ciclo de
pruebas. Para esto, es conveniente definir una serie de métricas que permitirán al finalizar un proceso
de pruebas, comparar los resultados obtenidos contra las métricas definidas, sí los resultados obtenidos
no superan la métricas definidas, no es posible continuar con el siguiente ciclo de pruebas.
Existen varios tipos de criterios de salida dentro de los cuales se pueden mencionar:
cubrimiento de funcionalidades en general, cubrimiento de funcionalidades críticas para el sistema,
Número de defectos críticos y mayores detectados, etc. También es importante aclarar que el proceso
de pruebas puede ser suspendido y/o paralizado, debido entre otros, a aspectos relacionados con el
presupuesto y la calidad mínima del sistema requerida para el inicio formal de pruebas.
Cierre del proceso
durante este periodo de cierre el cual históricamente se ha comprobado que se le destina muy
poco tiempo en la planeación, se deben cerrar las incidencias reportadas, se debe verificar si los
entregables planeados han sido entregados y aprobados, se deben finalizar y aprobar los documentos de
soporte de prueba, analizar las lecciones aprendidas para aplicar en futuros proyectos, etc.

DOCUMENTACIÓN DE LAS PRUEBAS

El registro de pruebas es un mecanismo empleado para tener un control detallado sobre las
pruebas realizadas en el sistema almacenando datos importantes para: resolución de problemas, análisis
de los procedimientos de desarrollo y mejoramiento de la calidad del software a nivel general. Es
necesario evaluar el proyecto a medida que se va construyendo, por lo tanto se hace necesario llevar a
cabo, en paralelo al proceso de desarrollo, un proceso de evaluación o comprobación de los distintos
productos o modelos que se van generando.
Entradas del registro
Ejecuciones: Se identificarán las ejecuciones realizadas sobre el sistema. Se deberá indicar el
número de ejecución de la prueba, la fecha de la ejecución de la misma y algún identificador que
identifique unívocamente la prueba.
 Resultados del procedimiento: Al final de cada prueba se indicarán los resultados obtenidos,
destacando número de pruebas pasadas con éxito, número de pruebas con resultados fallidos y número
de pruebas totales. A modo de complemento, debería adjuntarse, si es necesario, un listado con las
pruebas ejecutadas seguido de su resultado. Por ejemplo:
• Alta cliente Ok
• Alta Servicio Fail
Información sobre el ambiente de prueba: Se detallará el ambiente utilizado para realizar las
pruebas. Se describirá el entorno general de pruebas y en concreto las posibles configuraciones de
hardware a utilizar en las pruebas, así como las necesidades software y/o combinaciones de ambos.
Eventos anómalos Se adjuntará además lo producido por lo detallado en la siguiente sección.
Informe de pruebas: Incidencias
Todas las pruebas realizadas debieran tener una referencia al identificador de un caso de prueba,
de modo tal, que sea posible establecer una relación entre ambos y además, favorece a la trazabilidad
del requerimiento ya que el propio caso de prueba tendrá un claro punto de origen/creación, con lo cual
será posible saber en todo momento el estado en el que se encuentra una prueba y/o un caso de prueba.
 BIBLIOGRAFÍA
https://oa.upm.es/40012/1/PFC_JOSE_MANUEL_SANCHEZ_PENO_3.pdf (10/10/21)
https://pruebasdelsoftware.wordpress.com/tag/ejecucion-de-pruebas/ (10/10/21)
https://unpsjb.github.io/ids3t/pruebas.html#entradas-del-registro (10/10/21)