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

FORMATIVO

PLAN DE PRUEBAS

TECNÓLOGO ANÁLISIS Y DESARROLLO DE SISTEMAS DE

INFORMACIÓN (ADSI)

ADALBERTO SEGUNDO JIMENEZ CASTRO

SERVICIO DE APRENDIZAJE
SENA
2019
HISTÓRICO DE CAMBIOS

Fecha Versión Descripción Autor

Septiembre 2019 1.0 Creación del documento

¡Error! No se encuentra el origen de la referencia. 2

Í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 5
2.1. Ítems a probar (funciones) 6
2.2. Cuestiones de riesgo 6
2.3. Características a probar 6
2.4. Características que no se van a probar 7
2.5. Enfoque (estrategia) 7
3.1. Criterios de entrada 8
3.2. Criterios de salida 8
3.3. Criterios de suspensión 8
3.4. Criterios de reanudación 9
3.5. Criterios de éxito y fallo 9
5.1. Planificación 11
5.2. Recursos 11
5.2.1. Hardware 11
5.2.2. Software 11
5.2.2.1. Herramientas 11
5.2.3. Dotación de personal 11
5.2.3.1. Responsabilidades 11
5.2.3.2. Formación 11

¡Error! No se encuentra el origen de la referencia. 3

1. INTRODUCCIÓN

El plan de pruebas refleja el enfoque y la programación de todas las pruebas del

proyecto. Esta sección expondrá un breve resumen del producto que se va a probar.
Resume todas las funciones a alto nivel.

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.

¡Error! No se encuentra el origen de la referencia. 4

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 Adalberto Jimenez 1.0 Sena 2019

stakeholders

Plantilla caso de Adalberto Jimenez 1.0 Sena 2019

prueba

¡Error! No se encuentra el origen de la referencia. 5

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

¡Error! No se encuentra el origen de la referencia. 6

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.

Cumplir a cabalidad con los puntos mencionados anteriormente tanto en casos

prueba como en la ejecución de nuestro sistema de calificaciones siendo así un
sistema organizado y veraz contando con mantenimiento predictivo y correctivo.

¡Error! No se encuentra el origen de la referencia. 7

3. CRITERIOS DE TRANSICIÓN

A continuación se describen los criterios requeridos para las pruebas para poder
pasar de un estado a otro.
Cumplir con los requisitos del sistema los cuales son el sistema operativo y tener
conectado internet

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:
 Verificación y chequeo de dispositivos conectados
 Verificación conexión a internet
 Sistema operativo requerido
 Usuario registrado

3.2. CRITERIOS DE SALIDA

 No se detectaron fallas en el sistema
 Se ha completado el chequeo

3.3. CRITERIOS DE SUSPENSIÓN

Esta sección debería incluir criterios o condiciones que si ocurren, se deberían parar
las pruebas. Esta sección es muy importante, muchas veces se le pide al equipo de
pruebas que continúe con las pruebas con intentos en vanos por llegar al calendario
establecido cuando en realidad el software no está preparado para que se pruebe.
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.

¡Error! No se encuentra el origen de la referencia. 8

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

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

¡Error! No se encuentra el origen de la referencia. 9

4. ESTRATEGIA DE PRUEBAS

Pruebas de sistema
Entregar un sistema completo a la necesidad del cliente y Brindar capacitación a
cada uno de los roles que estén en contacto con el software para que tengan claro
las posibles fallas o averías que puedan haber en el sistema y tener claro que paso
deben seguir para cada caso

Pruebas de aceptación de usuario

Explicar paso a paso a cada uno de los entes involucrados con el sistema y que
mirar el comportamiento de ellos con el sistema de calificaciones

¡Error! No se encuentra el origen de la referencia. 10

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
 Monitor
 CPU
 Internet

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

5.2.2.1. Herramientas
 Tener una conexión estable de internet

5.2.3. Dotación de personal

5.2.3.1. Responsabilidades
Miembros del equipo de aseguramiento de la calidad y sus responsabilidades:
Adalberto Jimenez - Análisis y soporte

5.2.3.2. Formación
 Adalberto Jimenez - Desarrollador de software y Analista de Calidad

¡Error! No se encuentra el origen de la referencia. 11

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.

¡Error! No se encuentra el origen de la referencia. 12

7. ANEXOS

 Adalberto Jiménez Castro - Desarrollador de software y Analista de Calidad

 Celular 3046838182

¡Error! No se encuentra el origen de la referencia. 13