plan de test

Pharmacy Versión: 1.0Plan de test Base de Datos Fecha:

Plan de test

Versión 1.0

Historial de RevisionesFecha Versión Descripción Autor

Página 1 de 10


Tabla de contenidos

1. Introducción 4

1.1 Propósito 41.2 Alcance 4

2. Técnicas y Tipos de Testing 4

2.1 Test de integridad de base de datos y datos 42.2 Test de funcionalidad 42.3 Test de Inferfaz de Usuario 52.4 Test de Performance 62.5 Test de Seguridad y de Control de Acceso 62.6 Test de Falla y Recuperación 7

3. Criterios de Entrada y Salida 8

3.1 Plan de Prueba 83.1.1 Criterio de Entrada para el Plan de Prueba 83.1.2 Criterio de Salida para el Plan de Prueba 8

4. Entregables 8

4.1 Resumen de los Resultados de las Pruebas 84.2 Clases JUnit. 94.3 Indicadores de Control 9

4.3.1 Evolución de la Prueba 94.3.2 Cobertura de los Casos de Prueba 9

5. Testing Workflow 9

6. Entorno Necesario 9

6.1 Software Base para el Entorno de Prueba 9

7. Roles 10

Página 2 de 10


Plan de test

1. Introducción

1.1 Propósito

El propósito del plan de test es recopilar la información necesaria para planificar y controlar el esfuerzo de test para el proyecto. Describe cómo se probará el software.

1.2 Alcance

Los niveles de testing serán por pruebas unitarias y por pruebas de integración.

Los tipos de test incluidos en el plan son de integridad de datos, funcionalidad, interfaz de usuario, performance, seguridad y control de acceso, falla y recuperación. No se incluye testing de configuración ni instalación, ni de ciclos de negocio.

2. Técnicas y Tipos de Testing

2.1 Test de integridad de base de datos y datos

La base de datos y los procesos de base de datos se prueban como un subsistema dentro del proyecto.

Objetivo: Asegurar que los métodos de acceso y los procesos funcionen correctamente y que no generen corrupción de información.

Técnica: Invocar cada método de acceso y procesos, alimentándolos con datos válidos e inválidos o consultando información.

Inspeccionar la base de datos para asegurar que los datos han sido cargados como se pretendía, todos los eventos ocurrieron correctamente, o que la información fue recabada correctamente

Herramientas: Scripts de carga de información

Herramientas para backup y restore de la base de datos

Utilidades para ejecutar scripts SQL

Herramientas de generación de información

Criterio de éxito: Todos los métodos de acceso a datos y los procesos funcionan como fueron diseñados y sin corrupción de información

Consideraciones especiales:

Puede requerirse un entorno de desarrollo que permita el acceso directo a la base de datos para poder modificar los datos directamente.

Los procesos deben invocarse manualmente

Debe utilizarse una cantidad minima o pequeña de datos para incrementar la visibilidad de cualquier evento no acceptable.

El ambiente de testing debe ser lo más parecido posible al de producción.

Página 3 de 10


2.2 Test de funcionalidad

El test de funcionalidad verifica la correcta aceptación de los datos, su procesamiento, acceso, búsqueda y la apropiada implementación de los requerimientos, utilizando datos válidos e inválidos para la aplicación que se está testeando. El testeo funcional se hará unicamente para los Casos de Uso identificados como de alta criticidad para el flujo de negocio y de alto riesgo para el éxito del desarrollo.

Objetivo: Asegurar la correcta funcionalidad de la aplicación, incluyendo la navegación, la entrada de datos, el procesamiento, la consulta de información, la actualización y la búsqueda.

Técnica: Ejecutar cada escenario de los casos de uso que incluyan una función critica y de alto riesgo en el flujo de negocio, utilizando datos válidos y no válidos, verificando lo siguiente:

Se obtienen los datos esperados cuando se ingresan datos válidos

Se muestran los mensajes de error adecuados cuando se ingresa datos no válidos.

Cada regla de negocio se aplica adecuadamente.

Herramientas: Casos de uso, Reglas de negocio, Requerimientos funcionales.

Criterio de éxito: Todos los test han corrido con éxito.

Todos los defectos detectados fueron resueltos o fueron suspendidos de acuerdo a lo especificado por el cliente.


Se cuenta con los datos necesarios para testear

2.3 Test de Inferfaz de Usuario

El Test de Interfaz de Usuario (UI) verifica la interacción del usuario con el software. El objetivo de este test es asegurar que la UI provee el acceso y navegación apropiados a través de las funciones del objetivo del test. Además, el Test de UI asegura que los objetos gráficos funcionan como se esperaba y se ajusten a la conformidad del PMP o los estándares de la industria.

Objetivo: Verificar que:

La navegación a través de las aplicaciones reflejen las funciones pedidas por el usuario en la captura de los requerimientos, incluyendo la navegación de ventana a ventana, de campo a campo, y la utilización de métodos de acceso (teclas de tabulación, movimientos del mouse, hoy keys).

Los objetos de las ventanas y sus características puedan ser utilizados y funcionen con su correcto modo.

La ortografía y la gramática sea correcta (por lo menos en lo que respecta a la aplicación en castellano).

Técnica: Crear o modificar las pruebas de cada ventana para verificar la correcta navegación y el estado de los objetos gráficos para cada aplicación.

Herramientas: Especificaciones Suplementarias – GUI

Imagen Conceptual: Prototipo Ejecutable

Página 4 de 10


Criterios de éxito: Las pruebas con la interfaz han salido satifactorias y el usuario está satisfecho con las ventanas y la funcionalidad de los objetos de las mismas de ambas aplicaciones.


No todas las propiedades de la GUI gráfica utilizada pueden ser accedidas con facilidad y por cuestión de tiempo se dedicará mucha mayor importancia a la interfaz de la aplicación Front, que la de la aplicación Back.

2.4 Test de Performance

El test de performance es una prueba de funcionamiento en que los tiempos de respuesta, las tasas de transacción, y otros requerimientos no funcionales de performance se miden y evalúan. El objetivo es verificar que los requisitos de rendimiento se han logrado; por ejemplo, que el procesamiento de resultado del exámen y cálculo de respuestas correctas no sea mayor a cinco segundos (requerimiento no funcional). El test de performance es implementado y ejecutado en función de las condiciones de trabajo como por ejemplo la configuración y velocidad del hardware.

Objetivo: El objetivo de las pruebas de performance es demostrar que las funciones del sistema estén alineadas con los requerimientos de performance pedidos por el cliente y cumpla con especificaciones estándares de tiempos de respuesta aceptables.

Técnica: Se controlará que el tiempo de respuesta a cualquier acción no sea mayor de 2 segundos, con un rango de tolerancia de hasta 3 segundos. O sea, que cualquier acción no demorará más de 2 a 5 segundos.

Herramientas: Especificación de los Casos de Uso

Script de carga de datos (para probar performance con una cantidad considerable)

Alguna herramienta de monitoreo de registro, disco rígido, CPU, memoria

Criterio de éxito: Ninguna acción superará los cinco segundos de respuesta, siendo preferible, en caso de contar con el tiempo suficiente, optimizar aquellas que demoren más de dos segundos.


Por cuestiones de tiempo, no se harán pruebas masivas como de stress y de volumen, así que la idea es que este test se pruebe con una cantidad considerable, media, de datos cargados.

El test de performance no servirá para conocer cuál es el límite de registros que puede soportar la base de datos y manejar bien la aplicación.

2.5 Test de Seguridad y de Control de Acceso

Este test se enfoca en dos areas claves de la seguridad:

Seguridad a nivel de aplicación, como por ejemplo: el acceso a los datos o a las funciones del negocio

Seguridad a nivel de sistema, como por ejemplo: el acceso restringido a los usuarios por medio de la ventana de logging o no permitir que el aspirante, en caso de haber desaprobado el examen, pueda rendir nuevamente sino hasta transcurridos 3 meses desde aquella fecha de evaluación (ver Solicitud de Cambio de Requerimientos – 002.doc)

Página 5 de 10


Objetivo: A nivel de Aplicación: verificar que el usuario sólo puede acceder a las funciones del Front para rendir el examen, que no tenga la posibilidad de acceder a las respuestas del examen que está rindiendo o va a rendir, de que no pueda acceder a los datos de usuario y que no tenga los permisos del administrador.

A nivel de Sistema: Verificar que si el usuario o el administrador ingresaron mal el usuario y/o la clave, no puedan ingresar al sistema. Verificar que el aspirante que desaprobó un examen no pueda rendir sino hasta transcurridos los 3 meses desde la fecha de evaluación.

Técnica: A nivel de Aplicación: Identificar y listar cada tipo de usuario y el tipo de funciones y datos a los que tiene permiso consultar, modificar o borrar.

Se crearán casos de prueba para cada tipo de usuario y se probará que el usuario no puede acceder a ninguna funcionalidad o dato a los que no tenga permiso.

A nivel de Sistema: Se probará ingresar con claves erróneas, con usuarios erróneos. Se probará ingresar con caracteres raros y con demás set de pruebas erróneos e intencionalmente dañinos. También se reprobará un exámen y se controlará que no se pueda rendir de nuevo si la diferencia de fechas es mayor a tres meses.

Herramientas: Especificación de los Casos de uso, donde se especifica qué puede y qué no puede hacer cada uno de los actores.

Criterio de éxito: La funcionalidad y permisos de cada usuario está correctamente implementada. Las pruebas fueron exitosas. Las pruebas de logging fueron todas aceptadas.

Special Considerations: -

2.6 Test de Falla y Recuperación

El test de Falla y Recuperación asegura que los datos puedan recuperarse exitosamente tras alguna fallas de hardware o de software. Que los datos sean recuperados exitosamente significa que se pueden volver a consultar y modificar sin pérdida de datos ni inconsistencias.

Objetivo: Simular fallas y efectuar procesos de recuperación para restaurar la base de datos, las aplicaciones y el sistema a un estado conocido y deseable. Se incluirán las siguientes pruebas:

Interrupción de energía en la aplicación Front, mientras se están llenando los datos o mientras se está rindiendo el examen

Interrupción de energía en la aplicación Back, mientras se están cargando las preguntas o se está publicando un examen

Interrupción, incomunicación o apagado del servicio del SGBD, la base de datos

Interrupción de procesos: cierre de la aplicación Front durante la rendición de un examen, corte de la aplicación Back mientras se están cargando datos

Página 6 de 10


Technique: Para cada uno de los casos de prueba explicados en el Objetivo:

Interrupción de energía en la aplicación Front y Back: se apagará la PC en la que la aplicación se está ejecutando

Interrupción del servicio del SGBD: se simulará o se eliminará físicamente la comunicación con el controlador de la base de datos

Interrupción de procesos: se probará de cerrar la aplicación Front durante un examen, matando el proceso o con la cruz de cierre de la ventana de la GUI

Herramientas: Backups

Herramientas de monitoreo de registro, disco, CPU, memoria

Herramientas de configuración y/o de recuperación de datos

Criterios de éxito: Se considerarán aprobadas las pruebas de Falla y Recuperación cuando se efectúen los casos de prueba y se demuestre que no hubo corrupción de datos, ni pérdida. Con esto se asegurará que, tras una transacción interrupida, siempre se puede regresar al previo estado consistente.


Las pruebas de fallas y recuperación son altamente intrusivas. Los procedimientos que implican desconectar el cable de energía o apagar la PC pueden ser no deseables, sobre todo en los sistemas operativos modernos de hoy en día. En cuyo caso, se pueden utilizar métodos alternativos, como el uso de una herramienta de diagnóstico de software o similar.

Para llevar a cabo estas pruebas son necesarios permisos de administrador sobre las PC y la base de datos que se vayan a llevar a cabo.

3. Criterios de Entrada y Salida

3.1 Plan de Prueba

3.1.1 Criterio de Entrada para el Plan de Prueba

El Plan de Prueba comenzará a ejecutarse a partir del desarrollo de la cuarta iteración, donde se comienza con la fase de Construcción. Cada caso de uso, o funcionalidad, estará asociada a un ticket. A medida que los Implementers vayan finalizando los casos de uso y las funcionalidades especificadas en la Especificación de Requerimientos de Software (SRS), estos tickets, pasaran al estado Ready To Test. Es allí donde los testers comenzarán con las pruebas.

Conclusión: el plan de prueba comienza a ejecutarse cuando el primer ticket pase al estado “Ready To Test”.

3.1.2 Criterio de Salida para el Plan de Prueba

El Plan de Prueba finalizará cuando todos los tickets estén cerrados como inválidos o fixed. Los defectos críticos (tickets de prioridad High (2) o Highest (1)) que vayan encontrándose a lo largo de la ejecución de este plan deberán arreglarse. Los defectos más leves, de prioridad Lowest o Low, pueden negociarse con el usuario y corregirse en la siguiente versión.

Página 7 de 10


4. Entregables

4.1 Resumen de los Resultados de las Pruebas

Artefacto de RUP.

4.2 Clases JUnit.

Como se explica en la sección 1.2, Alcance, hay dos niveles de testing: de integración y unitarios. Los tests de integración estarán explicados en los casos de prueba y el resultado de los mismos será arrojado en el Resumen de los Resultado de las Pruebas. Los test unitarios, en su mayoría, se realizarán con JUnit.

4.3 Indicadores de Control

4.3.1 Evolución de la Prueba

Los defectos (bugs) encontrados en las pruebas serán reportados como tickets, que tienen un estado. (Ver documento: Milestones en Assembla.) Los estados de estos tickets: New, Accepted, Invalid, Ready To Test y Fixed serán usados para armar este indicador, que será adjuntado en el Informe de Avance de cada entrega formal a partir de la cuarta iteración.

4.3.2 Cobertura de los Casos de Prueba

Este indicador muestra una estadística sobre los casos de prueba. La cobertura nos mostrará cuántos casos de prueba hay planificados, cuántos hay disponibles, cuántos ejecutados y cuántos ejecutados OK:

Planificados: Cantidad de Casos a Ejecutar.

Disponibles: Los entregados por los Implementers al Tester Manager.

Ejecutados: Lo que el equipo de prueba probó.

Ejecutados OK: Lo que funciona bien. Los casos de prueba que dieron positivos.

El indicador de la Cobertura de los Casos de Prueba será adjuntado, junto con el de Evolución de la Prueba, en el Informe de Avance de cada entrega formal a partir de la cuarta iteración del proyecto.

5. Testing Workflow Se harán pruebas unitarias para cada caso de uso o funcionalidad y se ejecutarán los casos de prueba a

medida que los Implementers vayan liberando builds para testear.

Los casos de prueba se diseñarán de forma incremental. Se presentarán los más importantes en la entrega formal de la tercera iteración y en las siguientes iteraciones se irán perfeccionando y planeando los necesarios para cada iteración.

Los resultados de las pruebas se irán anotando en el Resumen de los Resultados de las Pruebas. Los que vayan dando Ejecutados OK, se cerrarán como fixed; los que no, se reabrirán como Accepted o New.

Al final de cada iteración, a medida que se vaya estabilizando la entrega incremental, se comenzará con las pruebas de integración.

Página 8 de 10


6. Entorno Necesario

6.1 Software Base para el Entorno de Prueba

La siguiente tabla indica el software base que se requiere para ejecutar el Plan de Prueba.

Software Version Tipo de SW o Notas Adicionales

7. Roles

Rol Responsabilidad Específica o Comentarios

Test Manager Brinda la supervisación de la gestión.

Sus responsabilidades incluyen:

Planeamiento y logística

Lograr acuerdo en caso de conflicto

Identificar los motivadores

Adquirir recursos apropiados

Presentar reportes de administración

Defender los intereses de las pruebas

Evaluar la eficacia del esfuerzo aplicado a las pruebas

Test Analyst Identifica y define los tests específicos a ser realizados.


Identificar ideas de Testing

Definir los detalles de las pruebas

Determinar los resultados de las pruebas

Documentar los pedidos de cambio

Evaluar la calidad del producto

Página 9 de 10


Rol Responsabilidad Específica o Comentarios

Test Designer Define el enfoque técnico de la implementación del esfuerzo de testing.


Definir el enfoque de Test

Definir la arquitectura de la automatización de Test

Verificar las técnicas de Testing

Definir los elementos a ser testeados

Implementar la estructura de Testing

Tester Implementa y ejecuta las pruebas.


Aplicar las pruebas

Ejecutar los casos de pruebas

Registrar los resultados

Analizar y recuperar pruebas fallidas

Documentar incidentes

Designer Identifica y define las operaciones, atributos, y asociaciones de las clases de prueba.


Definir las clases de prueba requeridas para soportar los requerimientos de testing como los definió el equipo de QC

Implementer Implementar los casos de uso y escribir casos de prueba unitarios y paquetes de prueba.


Crear pruebas unitarias y ejecutarlas para filtrar los defectos más notorios

Página 10 de 10

plan de test

Documents