Aseguramiento de Calidad – Derrama Magisterial Lima enero de 2005

GUIA DE ELABORACIÓN DE LOS

PLANES DE PRUEBA

Enero de 2005

Área de Sistemas – Confidencial Página 1 de 14

Aseguramiento de Calidad – Derrama Magisterial Lima enero de 2005

TABLA DE CONTENIDO

1 Introducción ........................................................................................................................3
1.1 Control de versiones......................................................................................................4
1.2 Distribución de Documentos.........................................................................................4
2 Requisitos para la elaboración del Plan de Pruebas.............................................................5
2.1 Ambientes de Testing....................................................................................................5
2.2 Documentación y Procedimientos.................................................................................5
3 Plan de Pruebas....................................................................................................................6
3.1 Planificación de las actividades de prueba....................................................................6
3.2 Casos de Prueba............................................................................................................7
3.3 Prueba Unitaria .............................................................................................................8
3.4 Datos para la realización de las pruebas......................................................................11
4 Herramientas utilizadas para el proceso de pruebas...........................................................12
4.1 Control de Configuración del Ambiente de Test........................................................12
4.2 Reporte y Seguimiento del Defecto ...........................................................................12
ANEXO A –Interfase entre módulos del sistema ..............................................................13

Área de Sistemas – Confidencial Página 2 de 14

Aseguramiento de Calidad – Derrama Magisterial Lima enero de 2005

1 Introducción
La medición de la calidad del producto o aplicación, es determinada de acuerdo a
la medición del cumplimiento de algunos factores. A continuación se mencionan
algunos de los factores que son verificados por el Proceso de Pruebas.

 Satisfacción: Grado en el que un programa satisface las especificaciones y

cumple los objetivos del usuario, así como también las características
implícitas que se espera de todo software.

 Confiabilidad: Baja presencia de incidentes durante la ejecución de las

pruebas, sistema colgado, en loop o wait, pérdidas de datos, resultados
erróneos y acciones inesperadas.

 Funcionamiento: La aplicación se ejecuta y responde de una manera

oportuna, aceptable y continua cuando está sujeta a las características
operacionales del mundo real, tales como carga, stress, y períodos muy
largos de operación.

 Integridad: Grado en el que se controla el acceso al programa o los datos

por usuarios no autorizados.

 Usabilidad: Esfuerzo requerido para aprender y operar la aplicación.

El alcance de este documento es definir el estándar que sirva para la

elaboración de los planes de pruebas y define las técnicas a aplicar en el
diseño de las diferentes pruebas que se realizaran al sistema y/o aplicación y
los elementos a definir para la determinación de cada una de las pruebas y la
manera de recoger los resultados de dichas pruebas.

Área de Sistemas – Confidencial Página 3 de 14

Aseguramiento de Calidad – Derrama Magisterial Lima enero de 2005

1.1 Control de versiones

En esta sección se indica las actualizaciones que ha tenido el documento de

aseguramiento de calidad, el mismo que debe ser evaluado en forma periódica.

VERSIÓN FECHA AUTOR NOMBRE DE ARCHIVO NOTAS DE REVISIÓN

1.0 02/2005 Guia_Elaboración_Planes_Prueba Versión original

1.2 Distribución de Documentos

El presente documento ha sido distribuido a la lista de personas mencionadas en

el siguiente recuadro. Cabe señalar que el presente documento podrá ser
actualizado, conforme a los cambios en la organización de sistemas, debiendo ser
actualizadas y reemplazadas las copias existentes.

LISTA DE DISTRIBUCIÓN PERSONAL - CARGOS

Área de Sistemas – Confidencial Página 4 de 14

Aseguramiento de Calidad – Derrama Magisterial Lima enero de 2005

2 Requisitos para la elaboración del Plan de Pruebas

2.1 Ambientes de Testing

Para llevar a cabo las pruebas se requiere de un ambiente independiente y

estable, el cual debe tener la misma configuración que el ambiente del cliente final.
Es decir un ambiente similar al de producción que contenga datos reales para la
realización de la prueba.

El ambiente de Testing, es independiente de Producción y Desarrollo de Sistemas,

y es utilizado en forma exclusiva para la construcción del producto, la identificación
y corrección de los defectos encontrados durante el proceso de pruebas.

2.2 Documentación y Procedimientos

Para la recepción de un sistema, aplicación y/o programa a probar se requiere

contar con la siguiente documentación:

 Arquitectura lógica del Sistema.

 Modelo de Proceso/Funciones.

 Modelo de Datos.

 Diagrama de Interfaces entre módulos, que indique el flujo de información a

través del Sistema.

 Diagrama de Interfaces con otros Sistemas.

 Requerimientos Funcionales, que indiquen claramente lo que debe hacer y

las validaciones requeridas para cada función.

 Especificaciones de programa, que indique claramente los requerimientos

funcionales que satisface los cálculos y validaciones consideradas.

 Lista de riesgos, de tal manera de minimizar a través de las pruebas la

posibilidad de que el riesgo se haga efectivo.

 Lista de Aplicaciones críticas.

Área de Sistemas – Confidencial Página 5 de 14

Aseguramiento de Calidad – Derrama Magisterial Lima enero de 2005

Con la documentación recibida, el Área de Control de Calidad adquirirá el

conocimiento adecuado del funcionamiento del sistema, así como las
funcionalidades requeridas por el usuario o cliente, lo que le permitirá elaborar el
“Plan de Pruebas”. Pruebas” y los “Casos de Prueba”, este último será sometido a
la revisión de los desarrolladores para asegurar una cobertura de test razonable.

3 Plan de Pruebas
El propósito de esta tarea es asegurar que la prueba sea consistente, cubra los
objetivos y se asignen los recursos humanos preparados, la conducción sea
eficiente, modular y sea posible de repetir o replicar.

3.1 Planificación de las actividades de prueba

Esta tarea se descompone en las siguientes actividades:

 Asignar los casos de prueba a los analista de calidad y cuando no se pueda

cubrir la pruebas, se solicite apoyo al área de desarrollo y mantenimiento.

 Identificar los módulos de la Aplicación (opciones de menú, submenús,

pantallas).

 Identificar los programas de, mantenimiento, listador, consulta, batch entre

otros.

 Identificar las transacciones de cada módulo (ingresar, consultar, calcular,

facturar, generar orden, aplicar pagos etc.)

 Desarrollar los Casos de Pruebas para verificar el comportamiento de cada

transacción.

 Registrar el análisis transaccional, es decir registrar la información de los

datos de prueba para cada transacción, los resultados esperados y los
resultados obtenidos.

 Definir la importancia de la transacción asignada por el usuario experto.

 Definir la prioridad de los módulos para la ejecución de las pruebas, es

decir definir la importancia de cada módulo en base a su criticidad.

Área de Sistemas – Confidencial Página 6 de 14

Aseguramiento de Calidad – Derrama Magisterial Lima enero de 2005

 Definir los ciclos de prueba

 Registrar las fallas encontradas.

 Verificar la resolución de las fallas

 Documentar la aceptación conforme de las pruebas.

3.2 Casos de Prueba

El elemento principal de las pruebas lo constituye el Caso de Prueba, cuyo

objetivo es derivar un conjunto de pruebas que tengan la mayor probabilidad de
descubrir los defectos en el software o aplicaciones de Back y Front Office.

Los casos de pruebas constan de unos datos de entrada, un procedimiento de

realización de la prueba, las funcionalidades que se pretenden probar y los
resultados esperados con la prueba. En él se especifican los datos de entrada, las
características del elemento (función, módulo, sistema completo) que se pretende
probar, y los resultados que se esperan con esa prueba.

Los puntos a considerar al momento de elaborar los casos de prueba son:

 Elaborar casos de prueba basados en el correcto funcionamiento del

sistema.

 Elaborar Casos de Prueba que exploren los límites y sus proximidades de

las condiciones de funcionalidad del sistema.

 Elaborar Casos de Prueba fuera de los límites indicados por la

funcionalidad, con el objeto de explorar las condiciones de auto-protección
del sistema y de su correcto funcionamiento.

 Profundizar los Casos de Prueba ya referidos en fechas, donde por alguna

eventualidad el sistema presente distinta funcionalidad (estudio de la
necesidad de utilizar distintos escenarios de prueba).

Se determina que en cualquier punto y estado del desarrollo del proceso de

pruebas, los casos podrán ser sometidos a revisión por parte del Jefe de Equipo
de Sistemas y Líder de Desarrollo, quienes podrán manifestarse sobre el alcance
de los casos de test.

Área de Sistemas – Confidencial Página 7 de 14

Aseguramiento de Calidad – Derrama Magisterial Lima enero de 2005

3.3 Prueba Unitaria

El objetivo de las pruebas unitarias es probar individualmente todos los elementos

básicos que componen el sistema, validando que esté conforme respecto a las
especificaciones del programa y requerimientos funcionales que satisfacen la
aplicación.

En esta prueba se crea un compromiso entre las pruebas no formales que realiza
el programador a la vez que se produce la codificación y depuración del programa,
y las pruebas formales que realiza el área de control de calidad con una buena
selección de las pruebas. De forma tal que con el menor número posible de Casos
de Prueba se detecten el mayor número posible de fallos, y segundo con una
buena selección de las funciones que se consideren claves por su importancia, a
las que se dedicará una especial atención.

Probar un elemento de software (una función, un módulo o todo el sistema) implica

diseñar un conjunto de casos de pruebas relacionados con los datos reales con
los que tiene que trabajar ese elemento de software.

Dentro de las pruebas unitarias se destacan las siguientes:

o Prueba de Campos

 Para los campos alfanuméricos, verificar que permita el ingreso de

letras, números y separadores como – o /.
 Para los campos numéricos, verificar el ingreso solamente de
números y si corresponde, el ingreso de decimales y/o valores
negativos.
 Para los campos con un rango definido, los valores límites e
inmediatamente fuera de ellos, además de valores críticos dentro del
rango.
 Para los campos con un conjunto de valores posibles, el valor
mínimo, el valor máximo y alguno que no pertenezca al conjunto.
 Para los campos de fechas, se deben considerar las fechas válidas,
de cambio de mes, año, etc., tomando el mismo criterio de los
campos con rango de valores.

o Prueba de navegación de pantalla

Área de Sistemas – Confidencial Página 8 de 14

Aseguramiento de Calidad – Derrama Magisterial Lima enero de 2005

 Verificar que se pueda realizar el recorrido lógico de ingreso de datos

en la pantalla.
 Verificar acciones de los botones (Leer, Ingresar, Modificar, Eliminar,
Imprimir, Agregar Fila, Eliminar Fila...etc.)

o Prueba de visualización de pantalla

 Para los diseños visuales (cosméticos) sólo se reportarán los errores

gruesos, considerados elementales, que produzcan efectos que se
consideren degradantes de la imagen del conjunto de objetos
visuales.
 Verificar ortografía
 Verificar que nombre de la pantalla debe coincidir con el nombre de
la rama del menú.

Para llevar el registro de los distintos resultados obtenidos en cada una de

las pruebas, se utiliza la planilla “Conformidad y Aceptación de Pruebas –
Procedimiento QA_TEST_002.

El objetivo de las pruebas unitarias es el siguiente:

 Detectar funciones incorrectas que poseen fallos de implementación.

 Funciones incompletas que precisan de mayor lógica para asegurar la total

funcionalidad de su interfase.

 Funciones que faltan que necesitan ser implementadas. Este tipo de errores
se detectan al intentar verificar la funcionalidad de alguna función.

 Funciones inútiles que no suministran ninguna funcionalidad, que no son

utilizadas por otros módulos.

Las pruebas unitarias comienzan una vez que se ha desarrollado, revisado

y verificado la sintaxis del código fuente. Un repaso de la información del
diseño proporciona una guía para el establecimiento de los casos de prueba
que más probablemente descubrirán errores de las categorías previamente
mencionadas. Cada caso de prueba debe ir acompañado de un conjunto de
resultados esperados.

Área de Sistemas – Confidencial Página 9 de 14

Aseguramiento de Calidad – Derrama Magisterial Lima enero de 2005

o Prueba de Modulo

El criterio general debe ser elaborar un caso de prueba con un alcance

suficientemente destructivo sin llegar a niveles cuya complejidad demande
un esfuerzo desmedido que sobrepase el tiempo considerado
razonablemente normal para cada tipo de tarea, tal como se describe en el
Manual de SLA, capitulo 8.1. Método para medir la carga del trabajo.

Se verificará el flujo de los datos dentro del módulo y su interacción con el

resto. Se considerarán las transacciones normales del módulo, como
también casos no válidos.

o Prueba de Integración entre los Módulos

Se debe verificar los impactos en otros módulos, esta verificación se realiza

de la siguiente manera:

 Considerar la Planilla de Interfaces (Anexo ?), la cual indica el

impacto de cada transacción en los diferentes módulos
 Realizar las verificaciones en las aplicaciones correspondientes
 Indicar la transacción al analista de calidad encargado de la prueba
del módulo que recibe el impacto.
 Verificar el resultado.

o Prueba Integral del Sistema

La prueba de todo el sistema se lleva a cabo cuando se han integrado todos

los módulos para conformar el sistema completo. En esta etapa, el proceso
de prueba tiene que ver con la detección de errores en la interpretación de
los requerimientos y se relaciona con la verificación de que el sistema total
proporciona la funcionalidad especificada en los requerimientos y que sus
características dinámicas cumplen con las planteadas en la definición del
manual del sistema y manual de usuario.

 Considerar para este caso los programas principales o centrales del

Sistema, (aquellos que consideran todas las transacciones que se
ingresan en el Sistema, para transformarlas ya sea en un listado,
facturación o balance.
 Verificar la consistencia de cada una de las transacciones
ingresadas
 Verificar los cálculos realizados

Área de Sistemas – Confidencial Página 10 de 14

Aseguramiento de Calidad – Derrama Magisterial Lima enero de 2005

Cuando se detecta un error, se corrige y por tanto el sistema se modifica.

Siempre que el software se modifica tras la detección de un error se deben
realizar pruebas de regresión, es decir, repetición de todas o parte de las
pruebas realizadas previamente, para asegurarse que la corrección de un
error no conlleva a la generación de otros. Tiempo y costes impiden
habitualmente la repetición de todas las pruebas previas, pero sería
prudente la selección de una porción de pruebas que se consideren claves.
Además, en un software modular con interfaces bien definidas, las pruebas
de regresión pueden limitarse al módulo que ha cambiado y a sus
interfaces.

3.4 Datos para la realización de las pruebas

Previo a la ejecución de las pruebas, se preparará para cada una de los tipos de
pruebas establecidas (pruebas unitarias, pruebas de módulo, pruebas integrales)
los datos que serán utilizados incluyen:

o Parámetros o Datos estáticos: son aquellos que no cambian durante la

ejecución de la prueba y deberán ser cargados previamente, como por
ejemplo aportes, intereses, características del docente etc. Estos datos son
la base para poder iniciar las pruebas.

o Datos transaccionales: son aquellos que se irán ingresando en las

transacciones para la ejecución de un proceso. Algunos de estos datos
serán definidos para simular un escenario de negocio; otros serán
resultados parciales de la prueba que serán utilizados en el proceso
siguiente. Ejemplo: otorgamiento de un crédito, entre otros.

o Resultados esperados: es el registro con antelación a la prueba del

resultado de la prueba, Ejemplo : Al procesar el ingreso de un pago al
cliente, el resultado esperado es que su deuda disminuya en el monto del
pago ingresado. Al crear un nuevo docente, el resultado esperado es que
exista el aporte como tal. .

Los resultados esperados es el punto de comparación para determinar si una

prueba fue exitosa o no.
El Equipo de Conversión de Datos y/o Base de Datos, proveerá los datos de
prueba requerido, los que serán visados por los usuarios y en conjunto con el Área
de Calidad determinarán los resultados esperados.

Área de Sistemas – Confidencial Página 11 de 14

Aseguramiento de Calidad – Derrama Magisterial Lima enero de 2005

4 Herramientas utilizadas para el proceso de pruebas

4.1 Control de Configuración del Ambiente de Test

El Control de la Configuración se llevará a cabo por medio del administrador de

Soporte Técnico y Base de Datos, quienes manejaran y controlaran las versiones
de la aplicación así como la promoción de los ambientes de test.. De esta forma se
tendrá una versión estable en el ambiente de test.

4.2 Reporte y Seguimiento del Defecto

El resultado del Test son los informes de los defectos (fallas encontradas durante
la ejecución de las pruebas), su registro se hace a través del formato QA-TEST-
002 conforme a la codificación de errores de control de calidad ANEXO B - del
Manual de Control de Calidad. Este requerimiento seguirá activo hasta la
resolución del problema por parte del área de desarrollo y mantenimiento.

Esta herramienta adicionalmente permite generar reportes y gráficas (capitulo 8 –

Manual de Control de Calidad) que ayudan a la evaluación de los recursos (tanto
de Testing como de Fábrica) y la situación de las aplicaciones que están siendo
testeadas.

Área de Sistemas – Confidencial Página 12 de 14

Aseguramiento de Calidad – Derrama Magisterial Lima enero de 2005

ANEXO A –Interfase entre módulos del sistema

Sec Desde Modulo A Modulo Acción - Transacción Descripción

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Área de Sistemas – Confidencial Página 13 de 14

Aseguramiento de Calidad – Derrama Magisterial Lima enero de 2005

Área de Sistemas – Confidencial Página 14 de 14