Software Test Plan

Test Plan

1 Contenido
2 Introducción ......................................................................................................................... 3
2.1 Objetivos ....................................................................................................................... 3
2.2 Miembros del equipo .................................................................................................... 4
2.3 Estrategia de prueba ..................................................................................................... 4
2.4 Alcance .......................................................................................................................... 5
2.4.1 Funciones a probar ............................................................................................... 5
2.4.2 Funciones a no probar .......................................................................................... 5
2.5 Riesgos y suposiciones................................................................................................... 5
2.5.1 Suposiciones .......................................................................................................... 5
2.5.2 Riesgos ................................................................................................................... 5
2.6 Definiciones y acrónimos .............................................................................................. 6
3 Criterios de aprobación y fallas ........................................................................................... 6
3.1 Criterios de aprobación ................................................................................................ 6
3.2 Criterios parcialmente aprobados ................................................................................ 6
3.3 Criterios desaprobación ............................................................................................... 6
4 Proceso de Testing ................................................................................................................ 7
4.1 Pruebas entregables ...................................................................................................... 7
4.2 Responsabilidades ......................................................................................................... 7
4.2.1 Planificación de las pruebas: ................................................................................ 7
4.2.2 Diseño de las pruebas:........................................................................................... 7
4.2.3 Implementación/ Ejecución de las pruebas: ......................................................... 7
4.2.4 Evaluación de las pruebas..................................................................................... 7
4.3 Planificación.................................................................................................................. 8
5 Requerimientos del sistema .................................................................................................. 9
5.1 Hardware ...................................................................................................................... 9
5.2 Software ........................................................................................................................ 9
5.3 Seguridad ...................................................................................................................... 9
5.4 Herramientas ................................................................................................................ 9
6 Bibliografía ........................................................................................................................... 9

2
 Test Plan

2 Introducción

El propósito del documento se basa en poder especificar que funciones se probaran

dentro del proyecto, el cual trata sobre las empresas constructora específicamente en el
control de boletas ya que ellos llevaban su registro en un archivo Excel, en donde con los
filtros de la misma herramienta podían ver el estado de la boleta, por lo que su método se
adecuaba pero no entregaba alertas u notificaciones que pudieran notificar los plazos de
vencimiento, por lo que este trabajo lo debían realizar manualmente y continuamente.
También el informe de evaluaciones es consolidado en Excel por una persona. A
la hora de presentar las calificaciones por cada obra en las reuniones de directorio, se
anexa una hoja adicional a cada informe de obra con las calificaciones correspondientes.
(RLung, 09-04-2014)
Actualmente el sistema tiene como propósito poder controlar las fechas de
vencimientos de las boletas a realizar, por lo que el sistema debería responder emitiendo
alertas y notificando en los plazos que se estipulan.
Por lo que en el plan de pruebas define que realizaran los miembros del equipo para
que puedan realizar diferentes pruebas al sistema en el cual puedan encontrar resultados
acordes a los alcances que se estipularan estos serán definidos a través de la
documentación entregada por el profesor encargado de la asignatura prueba de software.
A continuación, se mostrará un diagrama de componentes en donde de acuerdo a estos
mismos se podrá ir armando el documento del test plan para que se pueda entender mejor.

2.1 Objetivos
El objetivo de las pruebas es verificar la funcionalidad de los sistemas:
- Control de garantías de clientes
- Control de garantías de subcontratos

3
 Test Plan

Además de entregar los pasos para la aplicación correcta de las pruebas, estrategias,
posibles fallos o errores dentro de esta misma siempre y cuando estén acordes a las
especificaciones entregadas en la documentación y los periodos estipulados para las
pruebas.

2.2 Miembros del equipo

Testers Rol
Gissella Reyes Test manager
Alan Jeria Test design specification
Hong Xiang Test case specification
Claudio Vasquez Test result
Tabla 1

2.3 Estrategia de prueba

Con los documentos entregados y con los alcances definidos se pretende que el encargado
de las pruebas tenga claro los criterios que se deben tener en consideración para probar los
elementos del sistema tanto para el control de garantías de clientes y de subcontratos dado
que debe dar a conocer la gravedad de los posibles fallos que pueden ser altos, medios o baja
para alguna futura reparación.
A continuación, se explicará la estrategia:
• El sistema será tratado como una caja negra
• Los defectos que se encuentren estarán disponibles en un Word adjuntando una
imagen de la falla.
• El equipo de prueba tendrá acceso al entorno de prueba a través de la conectividad
HyperV.
• El Equipo de prueba verifica que todas las entradas necesarias requeridas durante el
diseño y la ejecución de la Prueba serán aprobadas por la Test Manager
• Las actividades de diseño de casos de prueba serán realizadas por el Tester 2.
• El entorno de prueba y las actividades de preparación serán propiedad de la
Universidad de Valparaíso.
• Test Manager revisará y aprobará todos los entregables de prueba
• El proyecto proporcionará planificación de pruebas, diseño de pruebas y ejecución de
las pruebas.
• El equipo del proyecto tiene el conocimiento necesario.
• No hay tiempo de inactividad del entorno durante la prueba debido a interrupciones
o arreglos de defectos.
• Durante las pruebas funcionales, el equipo de pruebas utilizará los datos creados y
precargados que están disponibles en el sistema en el momento de la ejecución.

• Los procesos de prueba estarán bien definidos, pero serán flexibles, con la capacidad
de cambiar según sea necesario.
• Los datos se emularán entorno del sistema tanto como sea posible.
• Las pruebas se medirán de acuerdo a ciertos criterios para aprobarlas o desaprobarlas.

4
 Test Plan

• Las fallas se medirán de acuerdo a gravedad de esta misma ya sea alta, media o baja.

2.4 Alcance
Para el proyecto las pruebas se dirigen principalmente a las pruebas de GUI y la validación
de algunos datos de entrada. Tenemos que dejar también en claro que no se solucionaran las
fallas que vayamos a encontrar ya que solo probaremos el sistema. El sistema que vamos a
probar será los documentos de garantía tanto de clientes como de subcontratos.
2.4.1 Funciones a probar
• Documentación entregada por el profesor
o TDD - SL2015 - V1 – 20171215
o 201904 - Documento de Análisis y Diseño (V 2 0) - R1 – VABB
o EJEMPLO - Notificación - Documento de Garantía Próximo a Vencer
o Paso a Paso - Iniciar Sesión.pdf
• Documentos de Garantía de Clientes:
o Boletas de garantía: Modo formulario y grilla
• Documentos de Garantía de Subcontratos
o Boletas de garantía: Modo formulario y grilla

2.4.2 Funciones a no probar

• Pruebas de rendimiento no se considerarán en las pruebas
• Todo lo no nombrado en el punto 1.4.1

2.5 Riesgos y suposiciones

2.5.1 Suposiciones
• La base de datos requerida específicamente CONTOSOUSAPP está disponible
• La base de datos CONTOSOUSAPP funciona correctamente y tiene datos fiables.

2.5.2 Riesgos
A continuación, se presentarán los riesgos que se pueden encontrar cuando se estén realizando las
pruebas:

• La disponibilidad del laboratorio 502 ya que es uno de los que menor disponibilidad tiene.
• Al ser 4 integrantes en el equipo es difícil tener un tiempo en común ya que nosotros tenemos
diferentes horarios y responsabilidades
• La documentación entregada no especifique su la correcta

5
 Test Plan

2.6 Definiciones y acrónimos

Palabra Significado
GUI Interfaz Gráfica de usuario
HyperV Virtualizador de imágenes
Tabla 2

3 Criterios de aprobación y fallas

Esta sección especifica los criterios genéricos de aprobación / rechazo para las pruebas
cubiertas en este plan. Se complementan con criterios de aprobación / falla en la
especificación de diseño de prueba. Tenga en cuenta que "fallar" en la terminología estándar
IEEE significa "prueba exitosa" en nuestra terminología.

3.1 Criterios de aprobación

Las pruebas ejecutadas en los componentes específicamente en la creación de las
boletas tanto para los Documentos de Garantía de Clientes y Documentos de Garantía de
Subcontratos serán aprobadas cuando no cumplan con los objetivos de la especificación de
diseño de los componentes, por lo que fallará y se informará un defecto / problema en el
sistema de seguimiento de defectos. Esto incluye pruebas positivas, pruebas negativas y de
estrés, y pruebas de límites.

3.2 Criterios parcialmente aprobados

Las pruebas ejecutadas en los componentes específicamente en la creación de las
boletas tanto para los Documentos de Garantía de Clientes y Documentos de Garantía de
Subcontratos serán medianamente aprobados cuando estos cumplan con sus requisitos y
fallen en ciertas partes.

3.3 Criterios desaprobación

Las pruebas ejecutadas en los componentes específicamente en la creación de las
boletas tanto para los Documentos de Garantía de Clientes y Documentos de Garantía de
Subcontratos serán desaprobadas cuando estemos probando ciertos componentes en los
documentos y no se encuentre ningún tipo de falla en estos.

6
 Test Plan

4 Proceso de Testing
4.1 Pruebas entregables

Entregables Encargado Fecha

Test Plan Project Manager 15-05-2019
Test completion report Project Manager 15-05-2019
Test design specification Tester 1 15-05-2019
Test case specification Tester 2 15-05-2019
Test result Tester 15-05-2019
Fallas Todos 15-05-2019

4.2 Responsabilidades
4.2.1 Planificación de las pruebas:
Reglas en las que se basará la prueba, incluidos los datos del proyecto.
Encargada Gissella Reyes- Test Manager
4.2.2 Diseño de las pruebas:
Identificar y describir los casos necesarios para realizar las pruebas.
Encargado Alan Jeria-Tester 2
4.2.3 Implementación/ Ejecución de las pruebas:
Proceso para configurar una prueba con datos de prueba y así evaluar la ejecución del
proceso, verificando los resultados, registrando posibles fallos, posibles resultados no
esperados.
Encargado Hong Xiang – Tester 3
4.2.4 Evaluación de las pruebas
Si se alcanzaron los criterios dichos de las pruebas y acorde a ello realizar informes
sobre la evaluación de pruebas.
Encargado Claudio Vásquez – Tester 4.

7
 Test Plan

4.3 Planificación

Nombre de tareas Tester Comienzo Termino Comentarios

Planificación del test Manager 29 Abril 1 Mayo
Leer el Syllabus Todos 29 Abril 1 Mayo
Leer documentación Todos 29 Abril 1 Mayo
entregada por el profesor
Se diseñaron las pruebas Tester 1 29 Abril 2 Mayo
Realizar informe de diseño Tester 1 29 Abril 2 Mayo
Aprobar los diseños de las Manager 2 Mayo 2 Mayo
pruebas
Realizar pruebas en los Todos 3 Mayo 8 Mayo
documentos (nombres)
Documentar fallas Manager 3 Mayo 8 Mayo Se encuentran en la
encontradas(Excel fallas) documentación entregada a
los Test Manager
Realizar informe de Tester 2 9 Mayo 12 Mayo
especificación de casos
Realizar informe de los Tester 3 9 Mayo 12 Mayo
resultados

8
 Test Plan

5 Requerimientos del sistema

5.1 Hardware
El sistema probado está montado sobre los computadores de la Universidad de Valparaíso
los cuales tienen las siguientes especificaciones:
• Procesador: i7-8700, Hexa core de 2.4 gh
• Memoria Ram de 8 Gb
• 100 Gb mínimo de disco duro

5.2 Software
• Dynamics SL: Microsoft Dynamics SL versiones iguales o menores a SL 2015
• Sistema operativo Windows 10
• Hyper -V
• SQL server 2014
• Visual Studio

5.3 Seguridad
• Necesita credenciales para poder acceder al sistema

5.4 Herramientas
Tester Herramienta
Test Manager Word, Excel
Test design specification Overleaf
Test case specification Overleaf
Test result Overleaf

6 Bibliografía
Anon., 2018. Syllabus. ISTQB 2018 ed. s.l.:s.n.

RLung, A. V., 09-04-2014. 201904 - Documento de Analisis y Diseño (V 2 0) - R1 - VABB, s.l.: s.n.