EL PLAN DE

PRUEBAS
 El plan de pruebas
Escribir un plan de pruebas permite
recopilar pensamientos, ideas y
conocimiento (experiencias).
Escribir un plan de pruebas permite
cristalizar ese conocimiento en una
forma concreta de abordar las
tareas futuras.
El plan de pruebas es una
oportunidad para comunicarse con
el equipo de pruebas, colegas de
desarrollo y gerentes (personas
involucradas).
El plan de pruebas

¿Cuántos planes de prueba se deben hacer?

• Ejemplo: Usted como administrador de pruebas, es
responsable de las fases de prueba de componentes,
integración y sistema, por tanto, tiene tres sub-proyectos
de prueba distintos para planificar y gestionar.
El plan de pruebas

¿Cuánto planes de prueba se deben hacer?

La recomendación • Diferentes periodos de

es hacer
diferentes planes pruebas
de pruebas, • Diferentes metodologías
debido a que se • Diferentes objetivos
diferencian en uno
o varios aspectos • Diferentes audiencias
El plan de pruebas - ¿Cuánto planes de prueba se
deben hacer?
Diferentes períodos de pruebas
• La planificación de la prueba, el
desarrollo de la prueba, la
configuración del entorno de
prueba y las tareas de ejecución de
la prueba para los sub-proyectos
comienzan y terminan en fechas
diferentes.
• Al escribir 1 plan de pruebas,
habrá grandes secciones marcadas
como "TBD" ("por determinar"),
lo que puede hacer sea difícil de
El plan de pruebas - ¿Cuánto planes de prueba se
deben hacer?
Diferentes metodologías
• Por ejemplo, las discusiones detalladas
sobre la instrumentación de cobertura
de código y las herramientas de prueba
de GUI automatizadas no van juntas.
• Otro ejemplo, las discusiones sobre
cámaras térmicas, acelerómetros y
pruebas de compatibilidad de
aplicaciones comerciales pueden crear
una mezcla demasiado diversa de temas
en un mismo plan de pruebas.
El plan de pruebas - ¿Cuánto planes de prueba se
deben hacer?
Diferentes objetivos
• Para el ejemplo inicial, si estoy tratando de
lograr tres objetivos diferentes: encontrar
errores en los componentes, encontrar
errores en las relaciones e interfaces entre
los componentes integrados
incrementalmente y encontrar errores en un
sistema completamente integrado, entonces
se debe escribir un plan para cada
componente.
• La prueba, la prueba de integración y la
prueba del sistema me permiten enfocar mi
pensamiento en cada objetivo de manera
independiente.
El plan de pruebas - ¿Cuánto planes de prueba se
deben hacer?
Diferentes audiencias
• El plan de prueba no es solo la
oportunidad de informar a colegas,
evaluadores y gerentes la visión.
• También es una oportunidad para
descubrir sus perspectivas.
• Un plan de prueba extenso que aborde
todos los ámbitos es posible que tenga
problemas para que la gente lo lea.
• Se puede crear más documentos que
respondan a las preocupaciones
específicas de las personas involucradas.
 El plan de pruebas - Plantilla
Descripción general Ejecución de pruebas
Caso de prueba y Aislamiento y Gestión de
Participantes Ciclos de Horas de
seguimiento de clasificación versiones de
clave errores prueba prueba
de errores prueba

Límites
Alcance Definiciones Ubicación
Historial de cambios
Riesgos de calidad

Calendario propuesto de hitos Riesgos y contingencias

Criterios de transición
De Ingreso De continuación De Salida
Documentos de referencia
Configuraciones de prueba y entornos

Desarrollo de las pruebas

Preguntas frecuentes
 Descripción general

Descripción general
Se puede ilustrar
conceptos tales como la
Permite presentar el
Aunque esta sección arquitectura del sistema
proyecto de prueba a los Se presenta una
debe ser bastante breve, que se va a probar, la
lectores, incluido lo que explicación concisa de
a menudo es útil incluir descomposición o
se va a probar y el las metas, metodologías
imágenes o gráficos segmentación del
enfoque general de las y objetivos.
simples. sistema para pruebas de
pruebas.
integración o
componentes.
Límites
• Se establecen límites para el plan
de pruebas discutiendo lo que se
probará y lo que no se probará.
• Se definen términos y acrónimos
importantes relacionados con la
prueba que se planea realizar.
• Se determina dónde y en qué
contexto se ejecutarán las pruebas.

Límites
Alcance
• Se demarca lo que se prestará
y lo que no se prestará Es No es
atención en el transcurso del Interfaz de usuario Compatibilidad de red
proyecto.
• Se puede usar una tabla del Compatibilidad de Seguridad y
tipo "Es / No es" para definir navegadores WEB privacidad
Alcanc el alcance de las pruebas.
• La columna Es, enumera los
Pruebas de usuario Compatibilidad con
Unix
e elementos que se incluyen
dentro del alcance de una fase
Rendimiento Usabilidad
de prueba. Capacidad Manejo de formato de
• La columna No es, especifica fechas
los elementos que no están
cubiertos dentro del alcance de
una fase de prueba.
Definiciones

Definiciones
• Las pruebas tienen sus propios términos y frases, por lo tanto,
se debe incluir una tabla de definiciones en los planes de
prueba.
• Una tabla de este tipo puede ayudar a aclarar la terminología
para aquellos que no tienen experiencia en el campo de las
pruebas y también puede ayudar a garantizar que todos los
miembros del equipo de pruebas operen con el mismo conjunto
de definiciones.
Ubicación
Se describe dónde se pretende
realizar las pruebas y la relación
que las organizaciones que realizan
las pruebas tienen con el resto de
la organización.
Puede ser tan simple como ”En el
departamento de pruebas".
En algunos casos, sin embargo, es
posible que la prueba se extienda
en múltiples locaciones.
Se puede armar una tabla que
muestre una ubicación tentativa de
las pruebas, como por ejemplo la
distribución geográfica del equipo

Ubicación de pruebas y que tipo de pruebas

realizarán, o que parte de las
pruebas, etc.
Riesgos de calidad
• Se resumen aquí los
riesgos de calidad, dado
que su propósito es tanto
comunicar como
planificar.
• Más adelante se verá todo
un tema orientado a
riesgos.
Riesgos de
calidad
 Calendario propuesto de hitos
Hito Fecha

Calendario Desarrollo y Configuración de las

pruebas
Plan de pruebas completado 09/08/2020
Laboratorio de pruebas 12/08/2020
definido
Laboratorio de pruebas 26/08/2020
configurado
Los planes de prueba contienen un calendario Set de pruebas completado 05/09/2020
para los principales hitos del proyecto de
prueba. Ejecución de pruebas
Inicio de las pruebas 02/09/2020
Se extraen de la estructura de desglose del Ciclo 1 completado 16/09/2020
trabajo.
Ciclo 2 completado 03/10/2020
Se centra en los hitos de alto nivel y los Ciclo 3 completado 13/10/2020
entregables que son visibles para la Fin de las pruebas 13/10/2020
administración.
Criterios de transición
Para cada fase de prueba, el
sistema sometido a prueba debe
satisfacer un conjunto mínimo
de calificaciones antes de que
el equipo de prueba pueda
ejecutar pruebas de manera
eficaz y eficiente.
Esta sección del plan de prueba
debe especificar los criterios
esenciales para comenzar y
completar varias fases de
prueba (y para continuar con un
proceso de prueba eficaz y
eficiente).
A medida que se escribe los
criterios de transición para las
fases de prueba, se debe tener
en cuenta lo que realmente
representa:
Ej. No tiene mucho sentido
iniciar pruebas exhaustivas de
un sistema en escenarios de
usuario si la aplicación no
puede abrir o guardar un
archivo o mostrar texto en la
pantalla.
"Si alguien fuera del grupo de
prueba no cumple con estos
criterios, no se puede
comenzar esta fase de prueba,
se debe parar esta fase de
prueba, o sugerimos que no se
avance en este proyecto ".
Criterios de transición – de ingreso

Los criterios de ingreso detallan lo que

debe suceder para permitir que un sistema
pase a una fase de prueba en particular.
Estos criterios deben abordar preguntas
como:
• ¿Están disponibles la documentación, el diseño y los
requisitos necesarios para que los testers puedan operar
el sistema y validar el correcto funcionamiento?
• ¿Está listo el entorno de pruebas (laboratorio, hardware,
software y soporte de administración del sistema)?
• ¿Están los utilitarios, accesorios y requisitos previos
disponibles de tal manera que los testers pueden usar?
Criterios de transición – de continuación

• El entorno de prueba debe

permanecer estable.
Definen aquellas • La acumulación de errores
condiciones y manejable.
situaciones que • Las pruebas en su mayor parte
deben prevalecer
en el proceso de
desbloqueadas (por ejemplo, por
prueba para errores grandes)
permitir que las • Las versiones de prueba
pruebas continúen instalables y estables deben
de manera efectiva entregarse de manera regular y
y eficiente: adecuada, y el cambio en el
sistema bajo prueba debe ser
conocido y controlado.
Criterios de transición – de salida

Ayudan a determinar cuándo se han completado las pruebas. Por

ejemplo:
• Se ejecutaron todos los casos de prueba planificados y las pruebas de
regresión.
• La dirección de proyectos considera que sus resultados están “bien”,
según la definición de completado.
 Configuraciones de prueba y entornos
Se documenta qué hardware, software, redes y espacio de laboratorio se usará
para realizar la prueba.

Se describe los detalles importantes de configuración que conviene mencionar.

Ej:
• Para una aplicación de PC, esta tarea puede ser tan simple como enumerar la media docena de
PC para pruebas.
• Dos o tres redes de prueba (suponiendo que la red sea un problema) y las impresoras, módems,
adaptadores de terminal y otros accesorios que pueda necesitar de vez en cuando.
• Navegadores de internet instalados y listos para usarse, etc.
• Sin embargo, suponga que está probando un sistema con importantes elementos de hardware
personalizados, uno con muchos elementos de hardware, o uno con costosos elementos de
hardware. En estos casos complejos, el uso de una tabla simple o una hoja de cálculo puede no
ser suficiente.
Desarrollo de las pruebas
En los proyectos de prueba se incluyen una
cierta cantidad de trabajo para diseñar y
En esta sección, se describe cómo el equipo de
desarrollar varios objetos de prueba, como casos
pruebas creará cada uno de esos objetos de
de prueba, herramientas de prueba,
prueba.
procedimientos de prueba, conjuntos de pruebas,
scripts de prueba automatizados, etc.

Si se utiliza pruebas manuales, se comunica si

Si se necesita datos de prueba, se explica cómo
tenemos la intención de escribir casos de prueba
se los obtiene.
detallados o utilizar cartas de prueba.

Si se va a realizar la automatización de pruebas

con herramientas de prueba existentes Si se crearán herramientas o utilidades de
(comerciales o gratuitas), se describe por qué se prueba personalizadas, se describirá cuáles son
usan las herramientas y cómo se pretende esas utilidades y cómo se pretende usarlas.
desarrollar scripts de prueba.
 Ejecución de las pruebas
Esta parte del plan de prueba aborda factores importantes que
afectan la ejecución de la prueba. Por ejemplo:
• Para ejecutar pruebas, a menudo necesita recibir elementos externos,
principalmente recursos (o financiación para esos recursos) y sistemas para probar.
• En el transcurso de la ejecución de las pruebas, recopilará datos que debe realizar
un seguimiento de una manera presentable para su equipo, sus compañeros y sus
gerentes.
• Además, ejecutará distintos ciclos de prueba en cada fase de prueba.

El nivel de detalle requerido aquí varía de un equipo a otro y de un

proyecto a otro.
Participantes clave

Se identifica a los participantes clave en Se identifica a los participantes externos,

el esfuerzo de prueba y el papel que y la información de contacto de cada
desempeñarán en la prueba. participante.

Otra parte útil de esta subsección puede

ser el proceso de escalamiento; en otras
palabras, si algunos participantes clave no
cumplen o no pueden cumplir con el
papel acordado, ¿qué sucede a
continuación?
Casos de prueba y seguimiento de errores
Esta sección trata sobre los
sistemas utilizados para
administrar y rastrear casos
de prueba y errores.
El seguimiento de casos de
prueba se refiere a la hoja de
cálculo o base de datos que
se utiliza para administrar
todos los casos de prueba en
los conjuntos de pruebas y
cómo se hace un seguimiento
del progreso a través de esa
lista.
El seguimiento de errores
tiene que ver con el proceso
que usa el equipo para
administrar los errores que se
encuentra a lo largo de las
pruebas.
 Aislamiento y clasificación de errores 1/3

Es importante ser explícito sobre el

Aislar un error significa
En esta sección del plan de prueba
experimentar con el sistema bajo
es donde se explica el grado en el
prueba en un esfuerzo por
que se pretende aislar errores y
encontrar variables conectadas,
clasificar los informes de errores.
causales o de otro tipo.
aislamiento de errores; de lo
contrario, el equipo de pruebas
puede terminar involucrado en la
depuración, una tarea de
desarrollador que puede consumir
mucho tiempo de los testers.
 Aislamiento y clasificación de errores 2/3
La clasificación de un reporte de error asigna el error a una categoría
particular que indica cómo se debe comunicar y manejar el error. Por
ejemplo:
• Fallo de requisitos. El informe de error se refiere a una falla del sistema para cumplir con sus
requisitos.
• Incumplimiento de no requisitos. El error informado no está cubierto por los requisitos del
sistema, pero afecta significativamente la calidad del sistema de manera inaceptable.
• Exención solicitada. El informe de error describe una falla, pero los desarrolladores solicitan
una exención porque creen que no afectará significativamente la experiencia de calidad de los
clientes y usuarios.
• Fallo externo. El informe de error aborda una falla que surge de un factor o factores externos o
más allá del control del sistema bajo prueba.
• Prueba de falla. Los desarrolladores creen que la prueba arrojó un error falso o no válido.
 Aislamiento y clasificación de errores 3/3

Muchos proyectos de desarrollo exitosos

utilizan un proceso de clasificación de errores
En lugar de clasificar los errores, algunos
para asignar prioridad a los errores y
equipos de proyectos utilizan un único proceso
determinar qué errores deben corregirse antes
de gestión de errores.
del lanzamiento. En ese caso, es posible que
desee describir ese proceso aquí.
Gestión de versiones de prueba 1/2

Una de las principales

interacciones entre el
En esta sección del plan
proyecto general y las
de prueba se define los
pruebas se produce ¿Con qué frecuencia
elementos clave del
cuando se envían aceptará una nueva
proceso de lanzamiento
nuevas revisiones, versión de prueba en el
de prueba que pueden
compilaciones y proceso de prueba?
afectar el esfuerzo del
componentes al equipo
equipo de pruebas.
de pruebas para su
prueba.
Gestión de versiones de prueba 2/2

Cada nueva versión de un

componente de software o
hardware en el laboratorio de
pruebas debe tener adjunto un
número de versión (revisión) o
un identificador. Este
identificador es esencial para
determinar qué versión del
sistema contiene un error, qué
versión corrige ese error, qué
piezas son compatibles con otras
piezas y qué versiones ha
probado.
Ciclos de prueba 1/2
Esta sección del plan de
prueba debe detallar sus
suposiciones y estimaciones
específicas sobre el
número, el tiempo y la
disposición de los ciclos de
prueba.

Por ciclo de prueba, se

entiende a ejecutar uno,
algunos o todos los
conjuntos de pruebas
planificados para una fase
de prueba determinada
como parte de esa fase.

Los ciclos de prueba suelen

estar asociados con una
única versión de prueba del
sistema bajo prueba.
 Ciclos de prueba 2/2
Generalmente, las nuevas versiones de prueba ocurren durante una fase de prueba, lo que
desencadena otro ciclo de prueba. Por ejemplo, si las suites de prueba 3.1 a 3.5 están planificadas
para una fase de prueba del sistema de tres ciclos, el primer ciclo podría implicar la ejecución de 3.1
y 3.2; el segundo ciclo, 3.3, 3.4 y 3.5; y el tercer ciclo, 3.1, 3.2, 3.3, 3.4 y 3.5.

Cualquier fase de prueba determinada implica al menos un ciclo a través de los conjuntos de pruebas
planificados para esa fase.

Cada ciclo subsiguiente generalmente implica una nueva versión de uno o más componentes del
sistema.
Horas de prueba
En algunos casos, se
necesita definir las horas
específicas de prueba.
Además, en algunos
proyectos se utiliza varios
turnos para mantener
activos los escasos recursos
durante 16 o 24 horas al día
para acelerar las pruebas.

En tales casos, se
define en esta
sección las horas y
turnos específicos
que se utilizarán.
 Riesgos y contingencias

Los temas pueden incluir necesidades de formación,

En esta sección se aborda eventos potenciales o
disponibilidad de soporte de desarrollo adicional para
probables que podrían hacer que el plan de prueba sea
la depuración si se encuentra una cantidad
difícil o imposible de llevar a cabo.
excepcional de errores, etc.
 Historia de cambios

Específicamente,
Esta parte del
puede asignar un
documento se registra
número de revisión y
los cambios y
registrar quién realizó
revisiones que se han
los cambios, cuáles
realizado al plan de
fueron esos cambios y
prueba en sí hasta este
cuándo se publicó la
momento.
revisión.
Documentos de referencia

Como regla general, un plan de

prueba se refiere a otros
documentos tales como
Enumerar estos documentos en esta sección
especificaciones permite
de diseño,
evitar la repetición extensa
requisitos, de su contenido.
conjuntos de pruebas,
cualquier documento de análisis
de riesgo de calidad y otra
información pertinente.
Preguntas frecuentes

En proyectos en los que Muchas de estas

se utiliza ingenieros de preguntas implican
pruebas y técnicos de describir la importancia
pruebas nuevos, esta es del proceso de
una sección muy útil. escalamiento de errores.