ESTRUCTURA Y ELEMENTOS DE UN PLAN DE PRUEBAS

(Borrador)

Preparado por Adrián Anex M – Dirección de Calidad

INTRODUCCIÓN

Las pruebas de software se aplican como una etapa más del proceso de
desarrollo de software, su objetivo es asegurar que este cumpla con las
especificaciones requeridas y eliminar los posibles defectos que este pudiera
tener. Generalmente las pruebas se apoyan en metodologías generales que
revisan los aspectos más fundamentales que debe considerar todo proceso de
prueba.

“El propósito del plan de pruebas es explicitar el alcance, enfoque, recursos

requeridos, calendario, responsables y manejo de riesgos de un proceso de
pruebas. Incluye identificación del plan de acción y fecha del plan, el alcance
que es el Tipo de prueba y las propiedades/elementos del software a ser
probado, los ítems a probar que son los elementos a probar y las condiciones
mínimas que debe cumplir para comenzar a aplicarle el plan.”

Un plan de pruebas está constituido por un conjunto de pruebas. Cada

prueba debe:

• Dejar claro qué tipo de propiedades se quieren probar (corrección,

robustez, fiabilidad, usabilidad,...).
• Dejar claro cómo se mide el resultado.
• Especificar en qué consiste la prueba (hasta el último detalle de
cómo se ejecuta).
• Definir cuál es el resultado que se espera (identificación,
tolerancia,...) ¿Cómo se decide que el resultado es acorde con lo
esperado?

Luego de culminadas las etapas de análisis, diseño y desarrollo se inicia la

etapa de pruebas, en esta etapa lo recomendable es que el aplicativo se
mantenga en un ambiente aislado o separado del ambiente de desarrollo o de
producción, lo ideal es preparar un ambiente de pruebas lo más parecido a
los ambientes que existen en producción para asegurar su correcto
funcionamiento en esa futura etapa

Para el analista de pruebas es muy importante y conveniente tener una

definición funcional y técnica razonable antes de iniciar el proceso de prueba.
Al probar hay que tener presente las siguientes máximas:

• Que usted no encuentre debilidades no quiere decir que no existan,

• Si usted no encuentra una debilidad, tenga por seguro que la

encontrará el usuario,

• Una prueba tiene éxito si encuentra un error o defecto.

• Las pruebas pueden encontrar fallos; pero jamás demostrar que no

los hay,

• Las pruebas sólo pueden encontrar los errores que buscan. Por
esto es tan importante un buen diseño de pruebas,

• Probar todo es lisa y llanamente imposible.

Tenga en consideración
Para que un software sea adecuado a las pruebas debe cumplir los siguientes
requisitos:

• Operatividad: El fallo debido a un error no debe interferir con las

pruebas posteriores, debe resolverse antes.
• Observabilidad: Deben existir formas de conocer las operaciones que
esta realizando el software
• Controlabilidad: Las salidas del software deben depender únicamente
de los datos de entrada, no dando lugar a aleatoriedades.
• Descomposición: Deben estar estructurado de tal forma que puedan
aislarse los problemas en componentes simples (modularidad)
• Simplicidad: Tanto funcional, como estructural y en el código.
• Estabilidad: Es recomendable que los cambios no interfieran en la
evolución del plan de pruebas.
• Facilidad de comprensión: Cuanta mas información contenga el código
o la documentación técnica adjunta mas fácilmente se desarrollaran las
prueba

Evolución del Plan

A medida que el proyecto evolucione este documento debe ser actualizado

periódicamente para reflejar las situaciones desarrolladas. Así, cada versión
del plan debería ser remplazada por el cambio de control, y cada versión
debería contener una agenda para actualizaciones subsiguientes del plan.
1 ESTRUCTURA DEL PLAN DE PRUEBAS

Este capítulo presenta los componentes que estructuran este marco y sirve
como una guía para la preparación de cualquier Plan de Pruebas

Características de una buena prueba

• Ha de tener una alta probabilidad de encontrar un fallo. Cuanto más,

mejor.
• No debe ser redundante. Si ya funciona, no lo probamos más.
• Debe ser la “mejor de la cosecha”. Si tenemos donde elegir, elegimos la
mejor.
• No debería ser ni demasiado sencilla ni demasiado compleja. Si es muy
sencilla no aporta nada, si es muy compleja a lo mejor no sabemos lo
que ha fallado

1.1.- Alcance
Indica el tipo de prueba y las propiedades / elementos de la aplicación a ser
probada.

1.2.- Configuración del ambiente de pruebas.

El primer factor que hay que tener en consideración es el ambiente de
pruebas. Este debe ser igual o muy similar al ambiente de producción donde
se pueda evaluar al sistema implementado, de manera equivalente.

1.3.- Estrategia de prueba

La estrategia de prueba que el producto que se implementando cumpla con los

requerimientos de la lógica del negocio que el GEC ha explicitado en su
contrato de servicio. Describe la técnica, patrón y/o herramientas a utilizarse en
el diseño de los casos de prueba

1.4.- Estado del plan de pruebas

Explicita las condiciones bajo las cuales, el plan de
ser: Suspendido, Repetido; Finalizado.

En algunas circunstancias (las cuales deben ser explicitadas) el proceso de

prueba debe suspenderse en vista de los defectos o fallas que se han
detectado. Al corregirse los defectos, el proceso de prueba previsto por el plan
puede continuar, pero debe explicitarse a partir de qué punto, ya que puede ser
necesario repetir algunas pruebas. Los criterios de culminación pueden ser tan
simples como aprobar el número mínimo de casos de prueba diseñados o tan
complejos como tomar en cuenta no sólo el número mínimo, sino también el
tiempo previsto para las pruebas y la tasa de detección de fallas.

1.5. Tangibles
Explicita los documentos a entregarse al culminar el proceso previsto por el
plan, por ejemplo especificación de pruebas, casos de prueba, bitácora de
pruebas, registro de errores
1.6.- Procedimientos especiales
Identifica las tareas necesarias para preparar y ejecutar las pruebas, así como
cualquier habilidad especial que se requiera.

1.7.- Recursos
Especifica las propiedades necesarias y deseables del ambiente de prueba,
incluyendo las características del hardware, el software de sistemas (por ej. el
sistema de operación), cualquier otro software necesario para llevar a cabo las
pruebas, así como la colocación específica del software a probar (por ej. qué
módulos se colocan en qué máquinas de una red local) y la configuración del
software de apoyo.

La sección incluye un estimado de los recursos humanos necesarios para el

proceso. También se indican cualquier requerimiento especial del proceso:
actualización de licencias, espacio de oficina, tiempo en la máquina del
ambiente, seguridad.

1.8.- Calendario
Esta sección describe los hitos del proceso de prueba y el grafo de
dependencia en el tiempo de las tareas a realizar.

1.9.- Manejo de riesgos

Explicita los riesgos del plan, las acciones mitigantes y de contingencia.

1.10.- Responsables y la matriz de responsabilidad

Especifica quién es el responsable de cada una de las tareas previstas en el
plan.

1.11.- Descripción de Requerimientos.

Esta sección del Plan de Pruebas contiene una lista de todos los
requerimientos que serán probados. Cualquier requerimiento no incluido en
esta lista estará fuera del alcance de las pruebas.

1.12.- Aprobación del Plan.

El Plan de Pruebas debe ser revisado por todos las partes responsables de
su ejecución y aprobado por el equipo de prueba, el líder proyecto y el Director
de Desarrollo e Internet.
2 CASOS DE PRUEBA

Para conocer como funcionara el sistema y tener una visión general de lo que
este hace para el negocio es necesario asimilar la documentación funcional
y técnica previamente definida. Luego de asimilar estos conocimientos será
más sencillo el desarrollo de los casos de prueba.

En las pruebas funcionales los casos de prueba tienen el objetivo de detectar

errores, los casos de prueba deben definir los datos de entrada a utilizar, el
proceso que debemos seguir en el sistema y el resultado esperado.

Una vez concluidos los casos de prueba es mas sencillo poder estimar cuanto
tiempo nos tomara una primera barrida de pruebas y con esto también
podremos realizar nuestro cronograma y plan de pruebas.

Los casos de prueba nos permitirán probar todas las funcionalidades del
sistema, sin embargo es importante tener buen criterio a la hora de
desarrollarlos. Las combinaciones de casos de prueba podrían ser
prácticamente infinitas.

Estructura para casos de prueba

• Identificador de caso de prueba.

• Módulo a probar
• Descripción del caso
• Pre-requisitos
• Data necesaria (valores a ingresar)
• Pasos o secuencia lógica
• Resultado esperado (correcto o incorrecto)
• Resultado obtenido
• Observaciones o comentarios
• Analista de Pruebas (responsable de las pruebas)
• Fecha de Ejecución
• Estado (concluido, pendiente, en proceso)

Ejemplo:

Id Caso Modulo a probar Descripción del Pre requisitos Fecha de la Comentarios Estado
de caso prueba a la prueba
prueba
CP001 Inscripción de Validar que un Debe existir el dd/mm/aa Pendiente
cursos alumno moroso alumno
(biblioteca o
financiero no Debe existir la
pueda inscribir carrera
ramos)
Debe existir la malla
Validar que el y los prerrequisitos
alumno pueda
inscribir
asignaturas
inherentes a su
 carrera.

Validar que un
alumno no pueda
inscribir ramos
que no tenga los
prerrequisitos
aprobados

Validar que el
alumno inscriba
un número
mínimo de
asignaturas
(Créditos)

3 ESQUEMA GENERAL DE LAS PRUEBAS

Las pruebas se harán en las siguientes categorías:

1. Usabilidad
2. Unitarias
3. Funcionalidad, de acuerdo a los procesos de negocios vigentes
4. Prueba de demanda “on line” (por ejemplo inscripción de asignaturas
(cursos)
5. Rendimiento (simulación de matrícula)
6. Integración, con los sistemas en producción
7. Carga masiva de datos (ficha prospectos)
8. Recuperación frente a una caída
9. Seguridad
10. Robutez
11. Aceptación
12. De huella de auditoría

3.1.- Pruebas de usabilidad

Estas pruebas están orientadas a probar la usabilidad del sistema. Esto se

refiere a probar la facilidad con lo cual los usuarios de una aplicación la pueden
operar. En nuestro caso, los objetivos principales serán:
• Determinar si los usuarios pueden utilizar las distintas funcionalidades
del sistema sin mayores complicaciones, es decir, ubican rápidamente la
función que desean ejecutar.
• Determinar si la interfaz es lo suficientemente intuitiva tanto para
usuarios que tienen experiencia como para aquellos que no la tienen.
• Determinar si la aplicación requiere modificaciones para que cumpla con
los objetivos anteriores.

3.2 Pruebas unitarias

Pretenden probar que los fragmentos individuales (unidades) que forman el
sistema cumplen las especificaciones y tienen el comportamiento esperado.

3.3 Pruebas funcionales

Se denominan pruebas funcionales a las pruebas de software que tienen por

objetivo probar que el sistema implementado cumpla con las funciones
específicas para los cuales han sido creado, es común que este tipo de
pruebas sean desarrolladas por analistas de pruebas con apoyo de algunos
usuarios finales, esta etapa suele ser la ultima etapa de pruebas y al dar
conformidad sobre esta el paso siguiente es el pase a producción.

A este tipo de pruebas se les denomina también pruebas de comportamiento o

pruebas de caja negra, ya que el analistas de pruebas, no enfocan su atención
a como se generan las respuestas del sistema, básicamente el enfoque de
este tipo de prueba se basa en el análisis de los datos de entrada y en los
de salida, esto generalmente se define en los casos de prueba preparados
antes del inicio de las pruebas.

Al realizar pruebas funcionales lo que se pretende en ponerse en los pies del

usuario. Generalmente se requiere apoyo de los usuarios finales ya que ellos
pueden aportar mucho en el desarrollo de casos de prueba complejos,
enfocados básicamente al negocio, posibles particularidades que no se hayan
contemplado adecuadamente en el diseño funcional.

El analista de pruebas debe dar fuerza a las pruebas funcionales y más aún a
las de robustez. Generalmente los usuarios realizan las pruebas con la idea
que todo debería funcionar, a diferencia del analista de pruebas que tiene más
bien una misión crítica, su objetivo será encontrar posibles debilidades en e
sistema bajo prueba

3.4 Prueba de demanda “on line” (por ejemplo inscripción de asignaturas

(cursos)

3.5 Rendimiento ( por ejemplo: simulación de matrícula)

A veces es importante el tiempo de respuesta, u otros parámetros de

rendimiento. Típicamente nos puede preocupar cuánto tiempo le lleva al
sistema procesar tantos datos, o cuánta memoria consume, o cuánto espacio
en disco utiliza, o cuántos datos transfiere por un canal de comunicaciones.
Para todos estos parámetros suele ser importante conocer cómo evolucionan al
variar la dimensión del problema (por ejemplo, al duplicarse el volumen de
datos de entrada).

3.6.- Prueba de integración

Las pruebas de integraciónse refieren a la prueba o pruebas de todos los
elementos unitarios, que comprueban la compatibilidad y funcionalidad de los
interfaces entre las distintas ‘partes’ que componen un sistema, estas ‘partes’
pueden ser módulos, aplicaciones individuales, aplicaciones cliente/servidor,
aplicaciones web, etc. Se realizan en el ámbito una vez que se han aprobado
las pruebas unitarias. Comprueban la correcta unión de los componentes entre
sí a través de sus interfaces, y si cumplen con la funcionalidad establecida

3.7 Carga masiva de datos (por ejemplo prospectos)

3.8 Recuperación frente a caídas

3.9 Seguridad

Se valida la funcionalidad del aplicativo para proveer una estructura de

permisos y acceso según sea el perfil del usuario

3.10 Prueba de robustez

Determinan la capacidad del aplicativo para no soportar entradas incorrectas.

Se prueba la capacidad del sistema para salir de situaciones embarazosas
provocadas por errores en el suministro de datos. Estas pruebas son
importantes en sistemas con una interfaz al exterior, en particular cuando la
interfaz es humana

3.11 Pruebas de Aceptación

Son las que harán de acuerdo a los criterios de aceptación. Determina que el
sistema cumple con lo deseado y se obtiene la conformidad del cliente. Estas
pruebas las realiza el cliente. Son básicamente pruebas funcionales, sobre el
sistema completo, y buscan una cobertura de la especificación de requisitos y
del manual del usuario.
4 ENTREGABLES

4.1 Suite de pruebas

La suite definirá los casos de prueba asociados a cada prueba.

4.2 Registros de pruebas realizadas

Servirá para identificar los casos de prueba y hacer seguimiento del estado de
cada caso de prueba. Los resultados de las pruebas serán resumidos
posteriormente antes de probar, probados, probados condicionalmente o
fallidos. En suma, se tendrán los siguientes atributos por cada prueba
realizada:
• Estado de la prueba
• Número de la versión probada
• Persona que realizó la prueba
• Fecha y hora de la prueba
• Notas y observaciones de la prueba

Será responsabilidad del QA actualizar el estado de la prueba en los registros.

Los resultados de las pruebas serán guardados bajo un control de versiones.

4.3 Reportes de defectos y errores

En la Intranet se almacenarán todos los resultados y defectos individuales y en
conjunto de las pruebas realizadas
ANEXO-1

GLOSARIO

Pruebas
Es una actividad en la cual un sistema o uno de sus componentes se ejecutan
para verificar el funcionamiento de un proceso, los resultados se observan y
registran para realizar una evolución de dicho proceso.
Referente a la programación una prueba de software, en inglés testing son los
procesos que permiten verificar y revelar la calidad de un producto software.
Son utilizadas para identificar posibles fallos de implementación.

Caso de prueba
Un conjunto de entradas, condiciones de ejecución y resultados esperados
desarrollados para un objetivo particular, un caso de prueba es utilizado por el
analista para determinar si el requisito de una aplicación es parcial o
completamente satisfactorio.

Calidad del software

Concordancia con lo requisitos funcionales y de rendimiento explícitamente
establecidos y con los estándares de desarrollo explícitamente documentados,
y con las características implícitas que se espera de todo software desarrollado
profesionalmente.

Defecto
Un defecto de software, es el resultado de un fallo o deficiencia durante el
proceso de creación de programas de ordenador o computadora u otro
dispositivo. Por ejemplo, un proceso, una definición de datos o un paso de
procesamiento incorrectos en un programa.

Error
Es una equivocación cometida por un desarrollador. Algunos ejemplos de
errores son: un error de escritura, una mala interpretación de un requerimiento
o de la funcionalidad de un método, una acción humana que conduce a un
resultado incorrecto. Por ejemplo: Divisiones entre cero. Es una tipo de
manifestación del defecto en el sistema que se ejecuta.

Falla
Puede presentarse en cualquiera de las etapas del ciclo de vida del software
aunque los más evidentes se dan en la etapa de desarrollo y programación. Es
la incapacidad de un sistema o de alguno de sus componentes para realizar las
funciones requeridas dentro de los requisitos de rendimiento especificados.

Verificación
La verificación del software es el proceso a través del cual se analiza y revisa
que el software satisfaga los objetivos propuestos al inicio del desarrollo.

Validación
El proceso de evaluación de un sistema o de uno de sus componentes durante
o al final del proceso de desarrollo para determinar si satisface los requisitos
marcados por el usuario.

Test Unitario
Prueba sobre componentes desarrollados individualmente.

Test de Integración
prueba que valida el funcionamiento coordinado de dos o más módulos
desarrollados por separado.

• Test Funcional
Prueba de usuario/cliente sobre funcionalidades desarrolladas.

• Test de Rendimiento
Prueba orientada a determinar la capacidad de la solución de HW/SW en el
escenario de producción esperado.