Capítulo 5

Capítulo 5
Criterio para el Diseño del Plan de Pruebas
1.Objetivo
Especificar los principales lineamientos y buenas prácticas para el diseño de un plan de pruebas.
2.Alcance
Este documento da soporte a los equipos involucrados en todos los servicios de QA y QC ejecutados
por Tsoft.
3.Responsabilidad
El Responsable de QA es el responsable máximo de concientizar a los equipos de QA sobre lo
establecido en este documento, como así también de su comunicación y capacitación.
4.Referencia
Norma ISO 9001 (La Versión Vigente de la Norma se define en el Registro de Documentos Externos del SGC).
5.Desarrollo
5.1. Definición. ........................................................................................................................................... 2
5.2. Alcance del Testing ........................................................................................................................... 2
5.3. Tipos de pruebas ............................................................................................................................... 2
5.4. Definición de la estrategia del testing ............................................................................................. 3
5.5. Criterios de aceptación ..................................................................................................................... 3
5.6. Supuestos y Restricciones ............................................................................................................... 4
5.7. Riesgos ................................................................................................................................................ 5
5.8. Participantes ....................................................................................................................................... 5
5.9. Ambiente de Pruebas ........................................................................................................................ 6
5.10. Herramientas .................................................................................................................................. 7
Aprobó su
En caso de que este documento esté impreso o se encuentre en una ubicación Elaborado y Aprobado por
Publicación
distinta a la especificada oficialmente para copias controladas en el procedimiento
“PRO-01 -Control de Documentos”, se convierte automática-mente en “COPIA NO K. Fernandez, P. Dedonato,
CONTROLADA” y es solamente para información. Walter Grasso
C. Plakoudakis
DOC-06 – Capitulo 5 - Criterio para el Diseño del Plan de Pruebas (Rev. 01)
1/7
TSOFT | Av. Belgrano 687 7P C1092AAG Buenos Aires, Argentina | Tel. (+54 11) 5128-3000 | www.tsoft.com.ar
Capítulo 5
PLAN DE PRUEBAS
5.1. Definición.
El plan de pruebas es un documento muy importante dentro del proceso de pruebas del
software. En él se explican los propósitos y enfoques de las pruebas, el plan de trabajo, los
procedimientos operacionales, las herramientas necesarias y las responsabilidades. La
extensión y detalle del plan debe adecuarse al proyecto y a las necesidades de la empresa,
pudiendo usarse como guía el estándar IEEE829.
El Plan de pruebas debe validarse siempre con los líderes funcionales y los usuarios, y es un
documento “vivo”, es decir que se debe ir actualizando a lo largo del ciclo de vida del testing.
Tener en cuenta la Identificación del plan de pruebas a través de un código, y el sistema al que
se aplica. Suele ser útil muchas veces explicitar la misión de la aplicación a probar, pudiéndose
complementar con un gráfico para describir mejor la aplicación y su contexto.
5.2. Alcance del Testing
Muchas veces conviene mencionar aquellas funcionalidades que van a ser probadas (no hace
falta nombrarlas detalladamente, pero sí agruparlas en grandes conjuntos o mencionar los
distintos entregables). De la misma manera, muchas veces es útil agregar un punto que sea
"Exclusiones del Alcance", mencionando aquellas funcionalidades y/o módulos que no se van a
probar (si los hubiera) y el motivo de esta exclusión.
a) Definición del alcance de las pruebas y las exclusiones del mismo. Elementos a
probar: qué módulos, clases, casos de uso se van a probar; cuando se emplea
desarrollo interactivo, debe especificarse las prestaciones (funcionalidades) a
probar y cuáles no se probarán (ya sea que se probaron antes o que se
implementarán más adelante)
b) Si se va a realizar una prueba de stress, es interesante incluir las transacciones

que van a ser estresadas.
5.3. Tipos de pruebas
Especificar los tipos de pruebas que se irán desarrollando a lo largo del proceso de testing.
Pruebas funcionales, de Integración, Regresión, Aceptación de usuarios, etc.
Es conveniente que se incluya una breve explicación de qué consiste cada una de estas
pruebas.
Para todas las pruebas, incluir las condiciones de inicio y de finalización de las mismas (este
punto es importante). La condición de inicio de ciclo, generalmente, es la prueba de humo
exitosa. Y la condición de finalización es ejecutar la totalidad de los casos de prueba según
Aprobó su
Publicación
C. Plakoudakis
2/7
Capítulo 5
alcance. Por lo general, para las pruebas de humo se utilizan un conjunto de casos de prueba
específicos.
En algunos casos, la condición del fin puede estar dada por la suspensión de la prueba por
diversos motivos. Para tal caso se debe dejar asentado en un documento esta circunstancia.
En cuanto a las pruebas de aceptación, no es posible planificar las pruebas sin la participación
de los usuarios, ellos tienen que probar, por lo tanto, tienen que formar parte de la planificación,
y se debe planificar qué usuarios participarán en las pruebas, probando qué módulos.
5.4. Definición de la estrategia del testing
Enfoque: vista general de la estrategia de prueba. Por ej. Se define si las pruebas serán
incrementales (voy probando distintos módulos en cada ciclo, hasta completar la cobertura) o
se cubrirá todo el alcance desde el ciclo 1; definir reasignación de los casos de prueba a
ejecutar en diferentes ciclos, etc.
Nota: Las pruebas modulares se recomiendan en el caso de que el proveedor de desarrollo

vaya completando su tarea con distintos entregables por módulos o grupos de módulos.
Preguntas que debemos hacernos a la hora de definir la estrategia de las pruebas:
a) Se utilizarán ciclos de prueba? Cuántos? De qué duración? Cuál es el objetivo principal de

cada ciclo?
b) Están definidas las regresiones? Qué evento dispara la realización de las mismas? Con qué
cobertura?
c) De qué forma se involucran a usuarios, analistas y programadores?
d) Está explicada la forma en que se comunicarán los defectos y se realizará su seguimiento?
e) Cada cuanto se emitirán informes de avance de test? Qué información contendrán? Quién
los elaborará? Quiénes serán las personas informadas?
f) Existen casos de prueba que pueden ser automatizados?
5.5. Criterios de aceptación
Criterio de aceptación o rechazo de las pruebas generales (go – no go a producción). En este

punto especificar si se va a salir a productivo con defectos de criticidad media abiertos Si es así
conviene dejarlo por escrito.
a) Ejemplo de los criterios de aceptación en un proyecto (esto puede variar según el cliente y
los usuarios referentes):
Para poder determinar la finalización de la actividad de pruebas, deberán cumplirse todos

los siguientes criterios:
 Deben cumplirse los Criterios de Aceptación Funcional:
El 100% de la funcionalidad debe haber sido entregada

90% casos de prueba deben haber sido ejecutados OK
Aprobó su
Publicación
C. Plakoudakis
3/7
Capítulo 5
Las incidencias abiertas respetan la siguiente Matriz de Aceptación:
Prioridad
Funcional /
Bloqueante Alta Media Baja Total
Severidad
Incidencia
Alta 0% 0% 3% 10% 13%
Media 0% 0% 5% 12% 17%
Baja 0% 2% 8% 15% 25%
Total 0% 2% 16% 37% 55%
Nota: Cada porcentaje se deberá calcular sobre el total de las incidencias reportadas durante la
prueba.
b) Criterio de aceptación o rechazo de un caso de prueba: criterio para dar por bueno o malo
un caso de prueba al ser ejecutado.
5.6. Supuestos y Restricciones
Un supuesto es todo aquello que Testing necesita para realizar las pruebas, y que da por
descontado que tendrá. Toda la información y recursos necesarios para la ejecución de los
tests debe estar disponible antes de comenzar dicha ejecución.
a) Tener en cuenta las tareas a realizar para satisfacer el proceso.
b) Necesidades ambientales: hardware, software y espacio de trabajo necesarios.
c) Responsabilidades: quién es responsable de cada cosa.
d) Personal necesario y si requieren entrenamiento.
e) Calendario: tiempos e hitos en el proceso.
f) Riesgos y contingencias que pueden ocurrir en el proceso de prueba.
g) Tener en cuenta los datos necesarios para ejecutar las pruebas. Es importante que antes
del comienzo de las ejecuciones de los casos se cuente con los sets de datos adecuados.
La búsqueda de datos puede llevar demasiado tiempo, es por eso que es conveniente
tenerlos de antemano para no consumir los tiempos previstos para la ejecución.
h) Cada archivo, tabla o base de datos necesario para realizar el testing esté disponible.
i) Haya espacio en disco disponible para la creación de archivos durante la prueba, para el
caso de que sea necesario generar archivos.
Aprobó su
Publicación
C. Plakoudakis
4/7
Capítulo 5
j) Todos los inputs están disponibles y ordenados.
En el caso de las restricciones, son todas aquellos límites que se nos imponen (del lado del
proyecto o su contexto), que condicionan nuestras acciones, y no podemos hacer nada para
evitarlas. Por ejemplo, si llegaran a existir restricciones temporales (fechas tope de fin de
pruebas), o legales, de ambiente de pruebas, de espacio físico para el equipo de trabajo,
deberían mencionarse en el plan.
Podrían existir, así mismo, restricciones en cuanto a la comunicación del grupo de test con
otros grupos del proyecto, disponibilidad de usuarios clave, etc.
5.7. Riesgos
Por definición, todo supuesto debe estar relacionado con un riesgo, es decir que debe haberse
definido un riesgo por cada uno de los supuestos explicitados.
A su vez, cada riesgo debe tener contingencias definidas en caso de que llegara a ocurrir.
Algunos ejemplos de riesgos que deberían contemplarse en los proyectos, e incluirse en el

plan, son:
a) Riesgos relacionados con los plazos, en función del tiempo para realizar las pruebas Qué
sucede si se debiera postergar la fecha de instalación en Producción? Qué sucede si se
atrasa desarrollo con las entregas a Testing?
b) Riesgos en función del impacto en el negocio, ante una suspensión en la disponibilidad de

la aplicación.
5.8. Participantes
Debemos definir todos aquellos grupos que participarán en las pruebas, los roles y
responsabilidades de cada uno de ellos, y el circuito en la comunicación durante los ciclos de
prueba.
Ejemplo:
Rol Responsabilidad / Descripción

[Nombre Lider equipo Definir la estrategia de pruebas
Empresa] QA/testing Definir los planes de Prueba
Ejecutar las pruebas
Coordinar las pruebas de aceptación
Armar el conjunto de datos necesario para la prueba
de integración
Emisión de Informes de Avance de pruebas
Emisión de Informe final de Pruebas
Aprobó su
Publicación
C. Plakoudakis
5/7
Capítulo 5
Analista Diseño de Casos de la Prueba
QA/Testing Carga de los casos de prueba en la aplicación
correspondiente
Ejecución de los casos de prueba
Registración y seguimiento de la carga de defectos
Análisis de los resultados de las pruebas
Administrador Aprobar la estrategia de prueba
del Ambiente de Armar el ambiente de pruebas de aceptación
Prueba Armar el ambiente de pruebas de integración
Administrador de Coordinar y administrar los distintos ambientes de
Ambientes pruebas necesarios para la correcta ejecución de las
actividades de testing.
Armar el entorno básico donde el equipo de QA podrá
configurar los productos, cargar los datos y ejecutar
las pruebas
Usuario Aprobar los planes de prueba
Responsable Seleccionar los datos de prueba a utilizar durante la
prueba de aceptación
Ejecutar las pruebas de aceptación
[NombreSistema] Responsable de Aprobar la estrategia de prueba
Sistemas Completar el resultado esperado en los planes de
prueba
5.9. Ambiente de Pruebas
La disponibilidad del ambiente de testing suele ser un factor crítico durante las pruebas, y un
condicionamiento en el comienzo de las mismas.
La gestión, disponibilidad, y los responsables de la misma, deben quedar claramente definidos

en el plan de pruebas.
Puntos a tener en cuenta en el análisis y planificación de los ambientes:
a) Está detalladamente especificado el ambiente de Test? Fue validado con los responsables
técnicos de su armado?
b) Está aclarado en el plan que ante cambios en lo que será el ambiente de Producción se
debe sincronizar el ambiente de Test?
c) Está aclarado en el plan que el uso de este ambiente es exclusivo para las pruebas
detalladas en el plan?
d) Están definidas las instanciaciones (replicaciones) del ambiente, siempre que sean
necesarias?
e) Es necesaria la creación de una o más instancias con alguna característica particular, en
función de los tipos de prueba que se quieran realizar?
f) Está definida la forma en que se pasarán objetos de Desarrollo a Testing? Y de Testing a
Producción?
g) Se utilizará control de versiones? Cuáles son los requisitos para modificar una versión?
h) Están definidos los mecanismos de población de datos en la base de Testing? Están
detallados? Están definidos los responsables?
Aprobó su
Publicación
C. Plakoudakis
6/7
Capítulo 5
i) Se definieron procedimientos de resguardo del ambiente? Y los de recupero?
j) En qué fecha estará disponible el ambiente de Testing? Será en etapas?
k) Se puede realizar un gráfico que aclare la arquitectura del ambiente de pruebas?
5.10. Herramientas
Especificar en un punto del documento, las herramientas que se utilizarán para llevar adelante
los ciclos de pruebas, características y requerimientos generales para su utilización. Establecer
permisos en el caso de que integrantes de otros grupos de trabajo requieran interactuar en el
testing a través de estas herramientas. En este último caso, tener en cuenta planificar la
capacitación correspondiente.
TIPS
 No es obligatorio terminar de testear cuando el producto está en producción. Continuar
testeando después de poner en producción el sistema puede ser una buena estrategia
para encontrar errores antes de que los encuentre el usuario final.
 Nunca se debe realizar el test sobre el sistema en el ambiente de producción.
 En cuanto a la prueba de aceptación, aclarar la manera en que se llevará a cabo y la
forma en que el usuario va a comunicar los incidentes que detecte. (si es que se efectúa
de manera informal, por afuera de la herramienta y sin casos de prueba).
 Detallar la cantidad de ciclos que tendrá la prueba, y contemplar ciclos opcionales
según la calidad de la aplicación.
 En el caso de que se implementen pruebas modulares, definir un Test de Integración.
 Definición de Circuito de comunicación entre grupos de trabajo, se pueden aplicar
básicamente dos soluciones (según decisión del equipo funcional):
1- Todos los defectos reportados por testing se derivan a Desarrollo, y éstos los
contestan a testing. En este caso el equipo funcional puede visualizarlos.
2- Los incidentes reportados por testing se derivan al Funcional, y éste los redistribuye
al equipo de Desarrollo. Cualquiera de las opciones es válida.
6.Diagrama de flujo
No Aplica.
7.Anexos
No Aplica.
Aprobó su
Publicación
C. Plakoudakis
7/7

Capítulo 5 - Criterios para El Diseño Del Plan de Pruebas

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Capítulo 5 - Criterios para El Diseño Del Plan de Pruebas

Cargado por

Copyright:

Formatos disponibles

Criterio para el Diseño del Plan de Pruebas

5.2. Alcance del Testing

b) Si se va a realizar una prueba de stress, es interesante incluir las transacciones

5.3. Tipos de pruebas

5.4. Definición de la estrategia del testing

Nota: Las pruebas modulares se recomiendan en el caso de que el proveedor de desarrollo

Preguntas que debemos hacernos a la hora de definir la estrategia de las pruebas:

a) Se utilizarán ciclos de prueba? Cuántos? De qué duración? Cuál es el objetivo principal de

5.5. Criterios de aceptación

Criterio de aceptación o rechazo de las pruebas generales (go – no go a producción). En este

Para poder determinar la finalización de la actividad de pruebas, deberán cumplirse todos

El 100% de la funcionalidad debe haber sido entregada

5.6. Supuestos y Restricciones

a) Tener en cuenta las tareas a realizar para satisfacer el proceso.

b) Necesidades ambientales: hardware, software y espacio de trabajo necesarios.

c) Responsabilidades: quién es responsable de cada cosa.

d) Personal necesario y si requieren entrenamiento.

e) Calendario: tiempos e hitos en el proceso.

f) Riesgos y contingencias que pueden ocurrir en el proceso de prueba.

Algunos ejemplos de riesgos que deberían contemplarse en los proyectos, e incluirse en el

b) Riesgos en función del impacto en el negocio, ante una suspensión en la disponibilidad de

Rol Responsabilidad / Descripción

5.9. Ambiente de Pruebas

La gestión, disponibilidad, y los responsables de la misma, deben quedar claramente definidos

Puntos a tener en cuenta en el análisis y planificación de los ambientes:

También podría gustarte