AP9-AA1-EV2-EJECUCIÓN DE PRUEBAS SOBRE EL PROYECTO FORMATIVO

Presentado por:
Edwin Urueta Rodriguez

SERVICIO NACIONAL DE APRENDIZAJE – SENA

Abril 2019
 PLAN DE PRUEBAS

Departamento/Proyecto/ Subtítulo

Departamento/Proyecto/ Subtítulo 2 Abril 2019

HISTÓRICO DE CAMBIOS

Fecha Versión Descripción Autor

Octubre 2018 0.9 Ronald Samuel
Creación del documento
Pérez Calderón

Departamento/Proyecto/ Subtítulo 3
Índice
1.1. Objetivos y tareas 4
1.1.1. Objetivos 4
1.1.2. Tareas 4
1.2. Audiencia prevista 4
1.3. Referencias 4
2.1. Ítems a probar (funciones) 5
2.2. Cuestiones de riesgo5
2.3. Características a probar 5
2.4. Características que no se van a probar 5
2.5. Enfoque (estrategia) 5
3.1. Criterios de entrada 6
3.2. Criterios de salida 6
3.3. Criterios de suspensión 6
3.4. Criterios de reanudación 6
3.5. Criterios de éxito y fallo 6
5.1. Planificación 8
5.2. Recursos 8
5.2.1. Hardware 8
5.2.2. Software 8
5.2.2.1. Herramientas 8
5.2.3. Dotación de personal 8
5.2.3.1. Responsabilidades 8
5.2.3.2. Formación 8

Departamento/Proyecto/ Subtítulo 4
1. INTRODUCCIÓN

El principal propósito de la evaluación es encontrar errores y defectos que puedan

existir en el uso del sistema a fin de corregirlos. Verificar que los validadores de
datos funcionen y limiten el ingreso de información, para que no se puedan ingresar
datos que no estén permitidos (sólo números en campos numéricos, por ejemplo).
Se quiere comprobar además que el sistema cumple con los requerimientos
establecidos por el usuario, tiene un rendimiento adecuado en el ambiente donde se
encuentra instalado. Otro aspecto importante a evaluar son las características de
seguridad relacionadas con el ingreso no autorizado de usuarios, de manera que no
puedan realizar modificaciones donde no sean permitidas

1.1. OBJETIVOS Y TAREAS

1.1.1. Objetivos
El propósito del plan de pruebas es proveer la información necesaria para planear y
controlar los esfuerzos de pruebas de un proyecto o iteración específicos. Describe
el enfoque para probar el software y es el plan general generado y utilizado por
administradores para dirigir el esfuerzo de pruebas.

1.1.2. Tareas
 Set de pruebas documentado incluyendo escenarios claros para el desarrollo
de las pruebas unitarias.
 Toda la documentación requerida debe estar disponible.

 Supervisar si se cumple las especificaciones de diseño establecidas por el

cliente.
 Supervisar si se cumple los requisitos del análisis que se hicieron en la
planificación del diseño y desarrollo del software.

 Realizar las pruebas necesarias de rendimiento y capacidad del sistema.

 Encontrar los problemas importantes y determinar los riesgos percibidos en
cuanto a la calidad del producto.

Departamento/Proyecto/ Subtítulo 5
1.2. AUDIENCIA PREVISTA
Por retiros de integrantes del grupo la audiencia se realizará por el Jefe de proyecto
el cual realizará todos los pasos de la prueba del software.

1.3. REFERENCIAS
Lista todos los documentos que se han utilizado para crear este plan, los que se usarán en
el desarrollo de casos de pruebas o durante la ejecución de pruebas. Estos se pueden listar
en una tabla como la siguiente:

Documento Autor Versión Localización

Plantilla Samuel Pérez 1.9 Sena2017/actividade

stakeholders s

Plantilla caso de Samuel Pérez 1.9 Sena2018/actividade

prueba s

Departamento/Proyecto/ Subtítulo 6
2. ALCANCE Y ENFOQUE

2.1. ÍTEMS A PROBAR (FUNCIONES)

La prueba de esfuerzo en un tipo de prueba de performance implementada y
ejecutada para encontrar errores cuando hay pocos recursos o cuando hay
competencia por recursos. Poca memoria o poco espacio de disco pueden revelar
fallas en el software que no aparecen bajo condiciones normales de cantidad de
recursos. Otras fallas pueden resultar al competir por recursos compartidos como
bloqueos de bases de datos o ancho de banda de red. La prueba de esfuerzo
también puede usarse para identificar el trabajo máximo que el software puede
manejar.
• Poca memoria o sin disponibilidad de memoria en el servidor
• Cantidad máxima de usuarios conectados
• Múltiples usuarios realizando la misma operación sobre los mismos datos
• Peor caso de volumen de operaciones.

2.2. CUESTIONES DE RIESGO

 Cliente escéptico
 Cliente insatisfecho por mala asesoría
 Altas Competencias
 Falta de Motivación al Cliente

2.3. CARACTERÍSTICAS A PROBAR

Las pruebas se realizarán con la siguiente criticidad en una escala de Alto, Media,
bajo (A, M, B).
 Pruebas de mantenibilidad……………………(A)
 Pruebas de fiabilidad ……………………. (B)
 Pruebas de escalabilidad ……………………(M)
 Pruebas de seguridad ……………………. (A)
 Pruebas de agilidad ……………………(B)

Departamento/Proyecto/ Subtítulo 7
2.4. CARACTERÍSTICAS QUE NO SE VAN A PROBAR

Las vías que pueden dificultar la determinación de los requisitos son:

● Los usuarios no se involucran en la elaboración de requisitos escritos

● Los usuarios insisten en nuevos requisitos después de que el coste y la
programación se hayan fijado.
● La comunicación con los usuarios es lenta
● Los usuarios no participan en revisiones o son incapaces de hacerlo.
● Los usuarios no tienen claro lo que desean los usuarios no comprenden los
problemas técnicos
● Los usuarios no entienden el proceso del desarrollo

Esto puede conducir a la situación donde las exigencias del consumidor

cambian, incluso cuando el desarrollo del producto ya está en marcha.

2.5. ENFOQUE (ESTRATEGIA)

Descripción de la estrategia de pruebas general para este plan de pruebas. Se han
de identificar las reglas y procesos asociados.

Departamento/Proyecto/ Subtítulo 8
3. CRITERIOS DE TRANSICIÓN

A continuación, se describen los criterios requeridos para las pruebas para poder
pasar de un estado a otro.

3.1. CRITERIOS DE ENTRADA

Lista todos los criterios que se han de satisfacer para empezar la ejecución de las
pruebas. Entre los posibles ítems que se pueden incluir están los siguientes:
- Casos de pruebas escritos y aprobados
 tipo de persona
 Entidad responsable
 Usuario
 Impresora Laser
 Hardware

3.2. CRITERIOS DE SALIDA

Lista todos los criterios que se han de satisfacer para que una fase de pruebas se de
por finalizada. Entre los posibles ítems que se pueden incluir están:
 mantenibilidad
 fiabilidad
 escalabilidad
 seguridad
 agilidad

3.3. CRITERIOS DE SUSPENSIÓN

Se aplicará este ítem si en los casos de prueba los elementos o puntos no cuentan
con las condiciones necesarias para llevar a cabo el proyecto tales como algoritmos
mal definidos o no funcionales, recopilación de elementos sin reconocimiento de
autor y por incorporación de elementos que no cuenten con pruebas que den
fiabilidad de su uso en el aplicativo.

3.4. CRITERIOS DE REANUDACIÓN

La reanudación de las pruebas se hace después de que el código haya sido
revisado y mejorado, después de ello se puede pasar nuevamente al plan de prueba

Departamento/Proyecto/ Subtítulo 9
3.5. CRITERIOS DE ÉXITO Y FALLO
Especificación de los criterios que se han de usar para determinar si cada una de las
pruebas ha tenido éxito o ha fallado.
Si las pruebas cumplen con los siguientes puntos se dará por entendido que ha
tenido éxito la ejecución de procedimiento
 Que tenga mantenibilidad
 Que sea fiable
 Que tenga escalabilidad
 Que sea seguro
 Que sea ágil en su ejecución

Departamento/Proyecto/ Subtítulo 10
4. ESTRATEGIA DE PRUEBAS

- En este punto nos enfocaremos en realizar tres diferentes tipos de pruebas

las cuales son:

 Prueba Unitaria: Verificar la funcionalidad y estructura de cada

componente.
 Prueba de Implantación: Verificar el funcionamiento del programa y
su rendimiento con hardware, software y aceptación de usuario.
 prueba del sistema: Verificar el sistema completamente incluyendo
todos los subsistemas con sus respectivas interfaces y el correcto
acople al resto de los componentes.

Departamento/Proyecto/ Subtítulo 11
5. PLANIFICACIÓN Y RECURSOS

5.1. PLANIFICACIÓN
Esta sección debería incluir una lista de hitos clave en las pruebas. Puede incluir:
- Aprobación del plan de pruebas
- Desarrollos de la lisara de casos de pruebas
- Desarrollo de los casos de pruebas
- Desarrollo de scripts de pruebas
- Preparación del entorno de pruebas
- Fechas de ejecución de pruebas

5.2. RECURSOS

5.2.1. Hardware
Requisito mínimo de hardware:
 Espacio disponible en disco duro de 500GB
 Memoria RAM de 1T
 Procesador de 1,60 GHz en adelante

5.2.2. Software
 Sistema operativo de 32 o 64 bits.

5.2.3. Dotación de personal

 Impresoras
 Laptops
 Dispositivos móviles

5.2.3.1. Responsabilidades
Miembros del equipo de aseguramiento de la calidad y sus responsabilidades:
 Ronald Samuel Pérez Calderón - Análisis y soporte

Departamento/Proyecto/ Subtítulo 12
 5.2.3.2. Formación
 Ronald Samuel Pérez Calderón - Desarrollador de software y Analista
de Calidad

Departamento/Proyecto/ Subtítulo 13
6. REVISIÓN DEL PLAN DE PRUEBAS

El Plan de Pruebas, contiene la definición de las metas y objetivos a probar dentro

del alcance de cada iteración del proyecto. Proporciona el marco de trabajo en el
que el equipo llevará a cabo la prueba dentro del horario coordinado.
 El Resumen de Resultados de Pruebas, organiza y presenta un análisis
resumen de los resultados de las pruebas y las medidas clave para revisar y
definir estas, típicamente por los Stakeholders claves. Además, puede
contener una declaración general de calidad relativa, puede mantener las
recomendaciones de las pruebas que se realizarán a futuro.
 La Lista de los Problemas, proporciona una manera de registrar para el
Administrador del Proyecto los: problemas, excepciones, anomalías, u otras
tareas incompletas que requieren atención que relaciona a la dirección del
proyecto.
 Cambios de Requerimientos. Se proponen cambios a los artefactos de
desarrollo a través de Cambios de requerimientos (CR). Se usan los Cambios
de Requerimientos para documentar los problemas, las mejoras solicitadas y
cualquier otro tipo de solicitud para un
cambio en el producto. El beneficio de CR es que proporcionan un registro de
decisiones, debido a su proceso de valoración, asegura los impactos del
cambio que puedan
darse en el proyecto.

Departamento/Proyecto/ Subtítulo 14
Departamento/Proyecto/ Subtítulo 15