PLAN DE PRUEBAS

Bogota/Mas Unidos.NET/ Grupo

Algoritmo

Marzo 2019
HISTÓRICO DE CAMBIOS

Fecha Versión Descripción Autor

10/03/2019 1 Luis manuel Londoño
11/03/2019 2 Mirley Valderrama

Bogota/Mas Unidos.NET/ Grupo Algoritmo 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 4
2.1. Ítems a probar (funciones) 5
2.2. Cuestiones de riesgo 5
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

Bogota/Mas Unidos.NET/ Grupo Algoritmo 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.

1.1. OBJETIVOS Y TAREAS

1.1.1. Objetivos
Realizar un sistema funcional para dar un mejor servicio a las victimas en Colombia

1.1.2. Tareas
Registro de funcionarios
Registro de usuarios
Documentos actualizados en la web
Servidor de descargas de documentos
Registro a diferentes programas que da el gobierno
.

1.2. AUDIENCIA PREVISTA

Describe la audiencia prevista de este plan. Habrá diferentes grupos potenciales dependiendo
de las fases de pruebas que se estén llevando a cabo. Entre ellos pueden estar:
- Equipo de pruebas: Equipos con Windows 7 en adelante
- Equipo de desarrollo: Luis Manuel Londoño
- Jefe de proyecto: Mirley valderrama
- Grupos de aseguramiento de la calidad: Unidad de victimas y entidades del Gobierno
- Etc.

Bogota/Mas Unidos.NET/ Grupo Algoritmo 4

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

Manuel Londoño 0.9 Bogotá

Mirley valderrama 0.9 Pitalito

Bogota/Mas Unidos.NET/ Grupo Algoritmo 5

2. ALCANCE Y ENFOQUE

2.1. ÍTEMS A PROBAR (FUNCIONES)

Autentificación de registro de usuarios y empleados
Descarga de documentos
Interfaz gráfica agradable
Un sistema ágil y rápido
Un sistema fácil de manejar

2.2. CUESTIONES DE RIESGO

Identifica qué software se ha de probar y cuáles son las áreas críticas, tales como:
- Entregable de un producto desarrollado por terceros.
- Capacidad de usar y entender una nueva herramienta
- Funciones extremadamente complejas
- Modificaciones de componentes con un histórico pasado de fallos
- Módulos o peticiones de cambio mal documentados
Hay algunos riesgos de software inherentes como la complejidad; éstos han de ser
identificados.
Otra posible área de riesgo es el mal entendimiento de los requisitos originales. Esto puede
ocurrir a nivel de gestión, usuario o desarrollador. Hay que tener en cuenta los requisitos que
no están claros y los que no se pueden probar.

2.3. CARACTERÍSTICAS A PROBAR

Listado de qué se ha de probar desde el punto de vista del usuario de lo que el sistema ha
de hacer. No es una descripción técnica del software, es una visión de los usuarios de las
funciones.
Hay que establecer el nivel de riesgo para cada característica. Se puede usar para ello una
escalan simple como Alto, Media, bajo (A, M, B). Estos tipos de niveles son entendidos por
el usuario.
Esta sección es muy parecida a la 2.1, pero se diferencias en el punto de vista.

2.4. CARACTERÍSTICAS QUE NO SE VAN A PROBAR

Listado de lo que no se va a probar desde el punto de vista del usuario y de los técnicos. No
es una descripción técnica del software.

Bogota/Mas Unidos.NET/ Grupo Algoritmo 6

Hay que explicar por qué estas características no se van a probar. Puede haber un amplio
número de razones: bajo riesgo, se ha utilizado antes y se considera estable; no está
incluido en esta versión del software…

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.

Bogota/Mas Unidos.NET/ Grupo Algoritmo 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.

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:
- Aprobación del plan de pruebas
- Entorno de pruebas estable y preparado
- Casos de pruebas escritos y aprobados
- Herramientas de pruebas preparadas
- Recursos para las pruebas disponibles

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:
- Completitud de los casos de pruebas
- Números y severidad de los defectos abiertos
- Paso de los objetivos de pruebas

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.

3.4. CRITERIOS DE REANUDACIÓN

En esta sección se listan los criterios que se deben satisfacer antes de que se puedan
reanudar las pruebas suspendidas.

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.

Bogota/Mas Unidos.NET/ Grupo Algoritmo 8

4. ESTRATEGIA DE PRUEBAS

Describe el enfoque general de las pruebas. Para cada grupo o combinación de

características hay que especificar el enfoque que asegurará que ese grupo de
características se va a probar adecuadamente. Hay que especificar las actividades, técnicas
y herramientas principales que se van a usar para cada uno de los grupos de pruebas
diseñados.
Existen diferentes grupos de pruebas que se pueden llevar a cabo. Para cada uno de ellos
hay que hacer una descripción, indicar las personas que van a llevar a cabo las pruebas y la
metodología que se va a seguir. Entre estos grupos están los siguientes:
- Pruebas unitarias
- Pruebas de Integración
- Pruebas de sistema
- Pruebas de carga
- Pruebas de aceptación de usuario
- Pruebas de regresión
- Etc.

Bogota/Mas Unidos.NET/ Grupo Algoritmo 9

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:
El objetivo de la Planificación del proyecto de Software es proporcionar un marco de trabajo
que permita al gestor hacer estimaciones razonables de recursos costos y planificación
temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo
de un proyecto de software, y deberían actualizarse regularmente medida que progresa el
proyecto. Además, las estimaciones deberían definir los escenarios del mejor caso, y peor
caso, de modo que los resultados del proyecto pueden limitarse.
Ámbito del Software.
Es la primera actividad de llevada a cabo durante la planificación del proyecto de Software.
En esta etapa se deben evaluar la función y el rendimiento que se asignaron al Software
durante la Ingeniería del Sistema de Computadora para establecer un ámbito de proyecto
que no sea ambiguo, e incomprensible para directivos y técnicos
Describe la función, el rendimiento, las restricciones, las interfaces y la fiabilidad, se evalúan
las funciones del ámbito y en algunos casos se refinan para dar más detalles antes del
comienzo de la estimación. Las restricciones de rendimiento abarcan los requisitos de
tiempo de respuesta y procesamiento, identifican los límites del software originados por el
hardware externo, por la memoria disponible y por otros sistemas existentes.
El Ámbito se define como un prerrequisito para la estimación y existen algunos elementos
que se debe tomar en cuenta como es:
La Obtención de la Información necesaria para el software. Para esto el analista y el cliente
se reúnen sobre las expectativas del proyecto y se ponen de acuerdo en los puntos de
interés para su desarrollo.

5.2. RECURSOS
Recursos.
La Segunda tarea de la planificación del desarrollo de Software es la estimación de los
recursos requeridos para acometer el esfuerzo de desarrollo de Software, esto simula a una
pirámide donde las Herramientas (hardware y Software), son la base proporciona la
infraestructura de soporte al esfuerzo de desarrollo, en segundo nivel de la pirámide se
encuentran los Componentes reutilizables.
Y en la parte más alta de la pirámide se encuentra el recurso primario, las personas (el
recurso humano).
Cada recurso queda especificado mediante cuatro características:
*Descripción del Recurso.

Bogota/Mas Unidos.NET/ Grupo Algoritmo 10

*Informes de disponibilidad.
*Fecha cronológica en la que se requiere el recurso.

5.2.1. Hardware
Windows 7/Windows Seven (La versión más actual de Windows, hasta la actual Procesador
de 32 bits (x86) o 64 bits (x64) a 1 Ghz (1.000 Mhz) o más.
Memoria RAM de 1 GB (1.024 MB) para 32 bits (x86) ó 2 GB (2.048 MB) para 64 bits (x64).
Espacio disponible en disco rígido de 16 GB (32 bits/x86) o 20 GB (64 bits/x64).
Dispositivo gráfico DirectX 9 con controlador WDDM 1.0 o superior.
Acceso a Internet (puede tener costes adicionales).
Según la resolución, la reproducción de vídeo puede requerir memoria adicional y hardware
gráfico avanzado.
Es posible que algunos juegos y programas requieran tarjetas gráficas compatibles con
DirectX 10 ó superior para un rendimiento óptimo.
Grupo Hogar requiere una red y equipos que ejecuten Windows 7.
Para la creación de DVD/CD se necesita una unidad óptica compatible.
BitLocker requiere el Módulo de plataforma segura (TPM) 1.2.
BitLocker To Go requiere una unidad flash USB.
Windows XP Mode requiere 1 GB adicional de memoria RAM, 15 GB adicionales de espacio
disponible en disco duro y un procesador habilitado para virtualización de hardware con Intel
VT o AMD-V activados.
Para escuchar música y sonidos se necesita una salida de audio.
Teniendo en cuenta los requisitos del Sistema Operativo y los programas que utilizamos
podemos sacar mayor rendimiento al equipo ya que un Sistema Operativo y programas más
actuales al requerir mayor potencia (Procesador, RAM, Disco duro,…) haran que el equipo
vaya más “lento”, mientras que un Sistema Operativo algo más “ligero” (y por regla general
más antiguo puede aportarnos algo de rápidez (Aunque tampoco hacen milagros) a la hora
de ejecutar programas, por ejemplo si tenemos un equipo que no “tira” con Windows XP una
alternativa puede ser utilizar Windows 2000 (Otra opción sería utilizar alguna distribución
Linux que no consuma muchos recursos)

5.2.2. Software
Los siguientes requisitos se aplican a todos los servidores del sistema de sitio:
Cada servidor de sistema de sitio debe usar un sistema operativo de 64 bits. La única
excepción es el rol de sistema de sitio de punto de distribución, que puede instalar en
algunos sistemas operativos de 32 bits.

Bogota/Mas Unidos.NET/ Grupo Algoritmo 11

Los sistemas de sitio no se admiten en las instalaciones de Server Core de ningún sistema
operativo. Una excepción son las instalaciones Server Core, que se admiten para el rol de
sistema de sitio de punto de distribución. Para obtener más información, vea Sistemas
operativos compatibles con servidores de sistema de sitio de Configuration Manager.
Después de que se instala un servidor de sistema de sitio, no se permite cambiar:
El nombre del dominio en el que se encuentra el equipo del sistema de sitio (también
conocido como cambio de nombre de dominio).
La pertenencia del equipo al dominio.
Nombre del equipo.
Si necesita cambiar cualquiera de estos elementos, primero quite el rol de sistema de sitio
del equipo. Después vuelva a instalar el rol una vez se haya completado el cambio. Para los
cambios que afectan al servidor del sitio, primero debe desinstalar el sitio. Después vuelva a
instalar el sitio una vez se haya completado el cambio.
Los roles de sistema de sitio no se admiten en una instancia de un clúster de Windows
Server. La única excepción a esto es el servidor de base de datos del sitio. Para obtener
más información, vea Usar un clúster de SQL Server para la base de datos de sitio de
Configuración Manager.
No se permite cambiar la configuración de tipo de inicio o de inicio de sesión de ningún
servicio de Configuración Manager. Si hace esto, es posible que impida que servicios clave
se ejecuten correctamente.

Herramientas
DVD con la iso o una USB
Listado de las herramientas que se usarán para llevar a cabo las pruebas.

5.2.3. Dotación de personal

Capacitaciones en cada actualización
Mantenimiento preventivo

6. Responsabilidades
Personal técnico y entidad o empresa

7. Formación
Listado de personal capasitado

Bogota/Mas Unidos.NET/ Grupo Algoritmo 12

8. REVISIÓN DEL PLAN DE PRUEBAS

Esta sección incluye planes para la revisión de este plan de pruebas. Se identifican los
grupos para revisar y aprobar el documento.
Hay que cerciorarse de que el plan de pruebas satisface los requisitos de desarrolladores y
clientes.

Bogota/Mas Unidos.NET/ Grupo Algoritmo 13

9. ANEXOS

Bogota/Mas Unidos.NET/ Grupo Algoritmo 14