PLAN DE PRUEBAS

Fernando Ramírez G.
PRUEBAS DE SOFTWARE
CONTENIDO

• Objetivo
• Secciones:
• Identificador
• Introducción
• Entregables
• Características a ser probadas
• Características a no ser probadas
• Criterios de aprobación y fallo
• Criterios de suspensión y reanudación
• Tareas de las pruebas
• Necesidades ambientales
• Capacitaciones
• Riesgos
• Laboratorios de usabilidad
 PLAN DE PRUEBAS

• Objetivo:
Comunicar a todos los involucrados del grupo de trabajo los entregables,
las característica a ser no o probadas, los criterios de aceptación y fallo, los
criterios de suspensión y reanudación, las capacitaciones requeridas por los
integrantes del grupo de pruebas, los riesgos, el laboratorio de usabilidad y
las necesidades ambientales.

El plan de pruebas se puede ajustar al

cualquier proyecto de software, se ajusta al
tamaño del proyecto, al tiempo, costo, el
ciclo de vida de desarrollo de software, los
involucrados entre algunos.
 SECCIÓN - IDENTIFICADOR

El identificador sirve para nombrar a plan de pruebas de

desarrollo, la característica de esta sección es que tiene que ser
único, no debe existir otro plan con el mismo identificador. El
objetivo de esta sección es llevar un mejor control de los
diferentes planes de prueba.
 SECCIÓN – INTRODUCCIÓN

a. Objetivo:
Finalidad genérica del plan de pruebas, no debe señalar
resultados concretos ni medibles con la utilización de
indicadores. Se debe especificar el propósito central del plan.
 SECCIÓN – INTRODUCCIÓN

b. Estrategia:
Corresponde al conjunto de decisiones sobres acciones y recursos a
utilizar que permitirá alcanzar el objetivo general del plan de pruebas.

• Existen muchas estrategias que pueden usarse para probar el

software. En un extremo, puede esperarse hasta que el sistema
esté completamente construido y luego realizar las pruebas
sobre el sistema total, con la esperanza de encontrar errores.
Este enfoque, aunque atractivo, simplemente no funciona. En el
otro extremo, podrían realizarse pruebas diariamente, siempre
que se construya alguna parte del sistema. Este enfoque, aunque
menos atractivo para muchos, puede ser muy efectivo.
 SECCIÓN – INTRODUCCIÓN
• Una estrategia de prueba que eligen la mayoría de los equipos de software se coloca entre los
dos extremos. Toma una visión incremental de las pruebas, comenzando con la de unidades de
programa individuales, avanza hacia pruebas diseñadas para facilitar la integración de las
unidades y culmina con pruebas que ejercitan el sistema construido.
Los 5 tipos de prueba del software
• Especificación: Este tipo de prueba incluye probar la aplicación en contra de la
documentación que se hizo antes, por ejemplo, que los procesos concuerden con los
algoritmos hechos a papel, o que la aplicación tenga todas las funciones que se habían
planeado.
• Usabilidad: Este tipo de prueba se refiere a asegurar de que la interfaz de usuario (o GUI) sea
intuitiva, amigable y funcione correctamente.
• Unidad: Este tipo de prueba solo aplica a proyectos grandes. Se divide el proyecto a unidades
y cada unidad es sometida a prueba individualmente.
• Integración: Prueba varias unidades juntas para asegurar que funcionen bien. También se
asegura de que las nuevas aplicaciones se integren con aplicaciones antiguas o aplicaciones
complementarias.
• Regresión: Esta prueba incluye todas las pruebas anteriores en caso de que se le haga algún
cambio a algún modulo después de haber sido puesto en ambiente de producción.
SECCIÓN – INTRODUCCIÓN
SECCIÓN – INTRODUCCIÓN
Otro ejemplo:
 SECCIÓN – INTRODUCCIÓN

c. Alcance:
Corresponde a presentar y delimitar la totalidad del trabajo que es
necesario para dar por terminado el plan de pruebas.
SECCIÓN – INTRODUCCIÓN
Otro ejemplo:
SECCIÓN – INTRODUCCIÓN
 SECCIÓN – INTRODUCCIÓN

d. Propósito:
Corresponde a la determinación firme de lo que se espera al
momento de llevar a cabo la implementación del plan de pruebas.
 SECCIÓN – ENTREGABLES

En esta sesión se listan todos los documentos que se entregaran como parte del
plan de pruebas, especificando características como el nombre del documento, la
persona quien entrega, la persona quien recibe, así como la fecha planeada y la
fecha que fue la entrega de cada uno de los entregables.

Es recomendable el uso de una tabla cuyo tipo de letra, color de la tabla

sean entendibles para que los involucrados en el plan puedan identificar
rápidamente las características de los entregables.
Algunos de los documentos que se ben considerar son: Casos de prueba,
especificación del diseño de casos, reporte de errores(defectos), evidencias de las
pruebas, reportes emitidos por algunas herramientas de administración de
pruebas, entre otros.
SECCIÓN – ENTREGABLES
SECCIÓN – CARACTERISTICAS A SER PROBADAS

En esta sesión se listan todas las características que serán probadas. Este debe
ser un trabajo mancomunado con los interesados del proyecto, los cuales
permitirán identificar que características se van a probar en el plan de pruebas.
Entre algunas características estarán la funcionalidad de interfaz grafica,
seguridad, etc.. Estas deben quedar definidas de manera clara y no queda a
interpretaciones.
SECCIÓN – CARACTERISTICAS A SER PROBADAS
SECCIÓN – CARACTERISTICAS A NO SER PROBADAS

En esta sesión se listan todas las características que no serán probadas. Este debe
ser un trabajo mancomunado con los interesados del proyecto, los cuales
permitirán identificar que características que no se van a probar y el riesgo que
puede ocasionar el no ser probadas en el plan de pruebas. Debe ser consensados.
Entre algunas características estarán la funcionalidad de interfaz grafica,
seguridad, etc.. Estas deben quedar definidas de manera clara y no queda a
interpretaciones.
SECCIÓN – CARACTERISTICAS A SER PROBADAS
continua Pla pruebas procuraduría
https://www.academia.edu/11909940/plan_de_pruebas