Plan de pruebas

Identificador del proyecto

Software de recursos humanos

Alcance
Lo que se pretende lograr con estos lineamientos es probar, evaluar el software y
todo lo que se ha conseguido durante el desarrollo de las fases anteriores, su
funcionalidad, sus características y si cumple de manera puntual con los
requerimientos del cliente, esto permite que el software de recursos humanos que
se pretende lograr pueda librarse de los errores. Hay que tener en cuenta que las
pruebas son imprescindibles en los proyectos de software ya que permiten
garantizar que las aplicaciones cumplan con las funcionalidades que se espera de
ellas y las expectativas de calidad (no solo de codigo); ayudando a encontrar esos
errores o defectos que aún no se han descubierto, reduciendo el costo del
desarrollo, el de propiedad para los usuarios; y desarrollar confianza en los
clientes al evitar los molestos errores de regresión.
Eso sin hablar de la sensación de seguridad incremental que se obtiene cuanto
más cerca estamos de un despliegue, ya que a más código que tenemos, más
pruebas nos aseguran (en forma de una tupida malla) que todo funciona
correctamente.

Ítems a probar
 Pruebas de validación: En esta se busca evaluar un sistema o uno de sus
componentes para determinar si satisface los recursos del cliente, en el
caso del software de recursos humanos, el de la empresa.

 Pruebas de verificación: con esta se pretende evaluar un sistema (o uno de

sus componentes) y de tal manera determinar si los productos de una fase
dada satisfacen las condiciones impuestas al inicio de dicha fase.

 Pruebas de unidades: durante esta prueba se evalúa el funcionamiento

individual de cada módulo, escribiendo casos de prueba para cada
funcionalidad o método en el módulo, de forma que se determine la
integridad del mismo, es decir se va evaluar cada funcionable del software.

 Pruebas de integración: Esta es una de las fases más importante y que el

software requerido debe cumplir cabalmente, debido a que las pruebas de
 integración pretenden verificar que los conjuntos de los módulos de un
sistema funcionan adecuadamente en conjunto.

 Pruebas de sistema: esta prueba se pone en práctica al final del desarrollo,

debido a que se deben incorporar a otros elementos del sistema y partiendo
de allí se realiza una serie de pruebas de integración.

 Pruebas de seguridad: comprueba que los mecanismos de protección

integrados en el sistema realmente lo protejan de irrupciones inapropiadas,
por lo tanto, el software de recursos humanos debe pasar por esta fase,
asegurando que lo que se va a entregar debe ser capaz de brindar
seguridad.

 Pruebas de rendimiento: está diseñada para probar el desempeño del

software entiempo de ejecución dentro del contexto de un sistema
integrado. Esta prueba, se aplica en todos los pasos del proceso de la
prueba, incluso al nivel de la unidad, basados en que el desempeño de un
módulo individual debe evaluarse mientras se realizan las pruebas.

Propósito:
El propósito del plan de pruebas planteado en este documento, es permitir
definir los lineamientos a seguir para realizar la planeación de la etapa de
pruebas sobre el proyecto “Administración de Recursos Humanos”,
planteando una estrategia que conduzca al objetivo enfocado en el
aseguramiento de calidad del software.

El propósito del Plan Maestro de Pruebas es:

 Proveer un artefacto central que gobierne la planeación y control del esfuerzo de
pruebas. Este define el enfoque general que será empleado para probar el
software y para evaluar los resultados de esas pruebas, y es el plan de más alto
nivel que será usado por los administradores para guiar y dirigir el trabajo de
pruebas detallado.
 Proveer visibilidad a los interesados en el esfuerzo de pruebas que han tenido
las consideraciones adecuadas para varios aspectos que orientan el esfuerzo
de pruebas, y dónde es apropiado que los interesados aprueben el plan.
 Este Plan Maestro de Pruebas también soporta los siguientes objetivos
específicos:
 Identificar los ítems que serán objeto de las pruebas.
 Enmarcar la metodología de pruebas que será utilizada
  Identificar los recursos requeridos y proveer un estimado del esfuerzo de
las pruebas.
 Elaborar un listado de los elementos entregables del plan de pruebas.

Alcance

El plan maestro de pruebas describe el detalle de las diferentes pruebas a ser

aplicadas, así como también las herramientas y metodologías a utilizar en cada una
de estas. Las pruebas que serán realizadas son:
 Revisión de la documentación: Consiste en revisar la calidad y completitud de
los documentos insumo y casos de uso para la ejecución de las pruebas.
 Pruebas Unitarias: Se validaran las piezas individuales del software como una
unidad independiente, bucles, condicionales, etc.
 Pruebas de integración: Se validara la integración entre los diferentes módulos
que componen la solución con el fin de garantizar que su operación integrada es
correcta.
 Pruebas Funcionales (procedimientos): Se validaran los procesos, reglas de
negocio establecidas y los requerimientos funcionales.
- Identificación de requerimientos funcionales.
- Tener en cuenta los requerimientos no funcionales.
 Pruebas de sistema: Las pruebas de sistema se determinarán en el momento
que el Outsourcing de Desarrollo entregue el documento de Requerimientos no
funcionales, y así determinar qué tipos de prueba se realizarán y a qué casos de
uso se aplicarán.
 Pruebas de regresión: Se validara que el sistema mantenga su correcta
funcionalidad debido a la incorporación de un ajuste, corrección o nuevo
requerimiento.
Adicionalmente y con el fin de centrar el plan de pruebas en ciertos factores que
son críticos y de mayor relevancia para el proyecto, se determinan los tipos de
pruebas que se realizarán para el proyecto, diseñando los factores de calidad y
las pruebas especializadas para alcanzar estos atributos del software entregado.
Con esta misión se identifican de acuerdo a las especificaciones del cliente los
factores
Para este proyecto de acuerdo a los requerimientos, se definen los siguientes
factores en los que se enfocarán las pruebas:
 Corrección.
 Conformidad.
 Facilidad de Uso.
  Portabilidad.
 Facilidad de Operación.

Referencias
- RUP: Proceso Unificado Rational
- Requerimientos de Software.
- Especificación de casos de uso.
Audiencia
En la parte de audiencia están involucradas y participan todas aquellas personas
involucradas directamente en:

 Obtener objetivos. Planeación

 Definir acciones
 Medir los
 Toma de decisiones
conocimientos
Aprobación  Etapas
 Definir Procedimientos
 Desarrollo
 Definir Pruebas Ejecución
 Realizar

Referencias
 Cronograma del Proyecto
 Especificación Requerimientos de Software:
- Requerimientos funcionales del Software.
- Requerimientos no funcionales del Software.

Misión de las Pruebas

 Contexto del Proyecto y Antecedentes
Realizar levantamiento y un posterior análisis de los procesos de Administración de
recursos humanos, con el fin de plantear una arquitectura de solución tecnológica
que permita la optimización, monitoreo y eficiencia de los procesos de negocio que
constituyen y representan valor en las objetivos estratégicos de la organización.
 Misión de las Pruebas aplicable a este proyecto
La misión de la evaluación para el presente proyecto se define enfocada al
aseguramiento de la calidad de los componentes y artefactos tecnológicos
desarrollados, de manera que estos cumplan con la especificación de los
requerimientos del cliente. Para esto se definen los siguientes lineamientos que
constituyen la misión y objetivos dentro este esfuerzo de pruebas:
 Descubrir tantos errores como sea posible
 Notificar acerca de los riesgos percibidos del proyecto
 Examinar la aplicación para comprobar si hace o no lo que se supone, debe
hacer. De igual forma verificar si ésta hace o no lo que se supone, no debe hacer.
 Validar y Verificar a través de la comparación del resultado de las pruebas del
aplicativo con el resultado que el mismo tendría que producir de acuerdo a su
especificación.
 Evaluar la calidad del producto y satisfacción de los interesados
 Cumplir con los requerimientos del cliente

Evaluación de Pruebas:
- Permitir detectar problemas desde el inicio de la especificación de
requerimientos.
- Disminuir riesgos.
- Obtener producto de calidad.
- Satisfacción del cliente.

Logros:
- La necesidad de optimización que presenta el cliente.
- Gestionar la ejecución de procesos.
- Verificar la confiabilidad de la información.

Adicionalmente existen unos motivadores puntuales que van a contribuir a que se

construya un software que satisfaga los requerimientos del cliente de la manera más
óptima posible y siguiendo un proceso adecuado para conseguirlo. Estos son:
 Aseguramiento de la calidad.
 Solicitudes de cambios.
 Riesgos de calidad.
 Verificación de los casos de uso.
 Comprobación de los requerimientos funcionales y no funcionales

Elementos Objetivo de Pruebas

A continuación se listan los elementos (artefactos, entregables, documentos etc.)
que serán objeto de prueba dentro del esfuerzo de pruebas:
Fase Inicial
 Documentación
 Especificación de Requerimientos
 Estimaciones
 Modelos - Diagramas
 PERSPECTIVA DE PRUEBAS PLANEADAS
Pasos ejecución de la pruebas
Diseñador
Ejecución

CHEQUEO PRUEBAS

Hay Cambios

Análisis
Diseñador
de pruebas de
Pruebas
Ejecución lista de chequeo Revisión
Pruebas de integración Documentación

Grupo Análisis No Hay Cambios Hay Cambios

de Pruebas

Pruebas de
funcionales

Hay Cambios
Pruebas de Regresión
Análisista
de
Pruebas No Hay Cambios

Pruebas de Sistema
Pruebas de Rendimiento

VISIÓN DE PRUEBAS Hay Cambios

Administrador
No Hay Cambios es de Pruebas
Repetir ciclo de pruebas
El plan de pruebas se basará en su totalidad en pruebas funcionales, instalación,
regresión y otras teniendo en cuenta los requerimientos no funcionales.
Revisión de la documentación: La estrategia para realizar estas pruebas,
consiste en la revisión de la documentación y casos de uso verificando su
completitud y concordancia en la información que se encuentra en ellos.
 Pruebas unitarias: Las estrategias para realizar estas pruebas consiste en
generar casos de prueba necesarios:
 Para que cada sentencia o instrucción del programa se ejecute al menos
una vez correctamente.
 Para que cada condición tenga por lo menos una vez un resultado
verdadero y al menos una vez uno falso.
 Para probar varias veces el mismo bucle (en donde aplique) considerando
los siguientes casos: Ignorar el bucle, pasar una vez, pasar dos veces,
pasar n veces, pasar n-1 veces y n+1 veces.

 Pruebas funcionales o de procedimientos: La estrategia para realizar estas

pruebas consiste en la elaboración y ejecución de Set de Pruebas, teniendo en
cuenta flujo normal y flujos alternativos, usando datos validos e inválidos que
permitan verificar lo siguiente:
- Uso de datos válidos.
- Uso de datos inválidos.

 Pruebas de Regresión: La estrategia para realizar estas pruebas consiste en

repetir las pruebas (funcionales y de carga) ejecutadas antes de corregir
defectos o de añadir nuevas funcionalidades, para comprobar que las
modificaciones no provocan errores donde antes no los había.

Pruebas de Aceptación

Las pruebas de aceptación se basarán en su totalidad en pruebas funcionales, instalación,

y otras teniendo en cuenta los requerimientos funcionales las pruebas. Adicionalmente
estas pruebas serán de caja negra.

 Pruebas funcionales o de procedimientos: La estrategia para realizar estas pruebas

consiste en la elaboración y ejecución de Set de Pruebas, teniendo en cuenta flujo
normal y flujos alternativos, usando datos validos e inválidos que permitan verificar los
casos de pruebas.

HERRAMIENTAS DE PRUEBA

Herramientas técnicas para las pruebas enfocadas en la reducción de riegos.

 Factor de Conformidad Técnica: Pruebas de
Prueba: operación
Descripción:
Con las pruebas de operación se garantiza que el usuario está bien capacitado
en el manejo del software y además se lleva un registro para guardar los
caminos no contemplados dentro de las pruebas previas del software, y con ello
se tomarán las medidas adecuadas.

Factor de Facilidad de Uso Técnica: Revisiones

Prueba:
Descripción:
Se debe incluir al cliente y/o usuario final con un rol de evaluador durante sesiones
de revisión en las cuales se discutirán los escenarios de calidad referentes a la
usabilidad del software.
Líder: Coordinador Proceso:
Diseño Código - Revisión paso a paso pseudo
código.

Factor de Facilidad de Pruebas de

Técnica:
Prueba: Operación Requerimientos
Descripción:
Validar los requerimientos no funcionales de ambiente recolectados con el cliente
versus las características requeridas por el ambiente de producción.
Requerimientos funcionales:
- GUI
- Tiempos de respuesta.
- Mensajes.

Pruebas de Integración
Las pruebas de integración que se realizaran durante el proceso de desarrollo de
los componentes de software, deben seguir las siguientes políticas y lineamientos
de ejecución:
 Se tiene una fase de pruebas unitarias competa y aprobada para el inicio de las
pruebas de integración.
 Probar en primer lugar los componentes o módulos individuales del software y
posteriormente y de manera progresiva se Irán agrupando hacia arriba y de
 manera funcional estos componentes para probar escenarios que impliquen
varias funcionalidades de interacción entre los componentes, y se continuará así
hasta llegar al nivel más alto de funcionalidad e integración.
 Para la ejecución de estas pruebas se utilizarán las siguientes técnicas:

OBJETIVO DE LA TECNICA
Verificar el funcionamiento interno de los componentes desarrollados por medio de la
comprobación de los procedimientos llevados a cabo por el software en cada
invocación/llamado/respuesta, así como el procesamiento de datos que tiene lugar en
cada uno de esta acciones.
TÉCNICA
Pruebas de Caja negra
ENTRADA SALIDA
PROCESO

HERRAMIENTAS
- DEPURAR - ROBOT DE PRUEBAS - SEGUIMIENTO DE VARIABLES

JUICIO DE ÉXITO
* Concordancia de los procedimientos del sistema con los requerimientos de usuario
 Optimo manejo de excepciones y errores
 Fácil seguimiento de la ejecución por medio de los traces.

OBJETIVO DE LA TECNICA
Verificar que los componentes funcionen adecuadamente de manera individual cuando
se encuentran integrados con otros módulos y componentes
TÉCNICA
Pruebas de Regresión
HERRAMIENTAS
- DEPURAR - ROBOT DE PRUEBAS - SEGUIMIENTO DE VARIABLES

JUICIO DE ÉXITO
 No se detectan errores inyectados durante la integración del sistema
 OBJETIVO DE LA TECNICA
Verificar que la parametrización de componentes y todos los aspectos referentes a la
integración de partes del software (consideraciones, configuraciones, ajustes) cumplan
con lo preestablecido pro el equipo desarrollo en la fase de diseño.
TÉCNICA
Listas de Chequeo
HERRAMIENTAS
Listas de chequeo con los items a comprobar para la integración

JUICIO DE ÉXITO
 El 100% de los ítems han sido chequeados y cumplen con la condición para ser
aprobados.

CRITERIOS DE ENTRADA Y SALIDA

 Criterios de Entrada del Plan Maestro de Pruebas

- Set de pruebas completo y claro.

- Claridad en el procedimiento para el desarrollo de las pruebas.
- Toda la documentación requerida para la realización de las pruebas debe estar
- disponible.

 Criterio de Salida del Plan Maestro de Pruebas

- Que todos los set de pruebas diseñadas para cada caso de uso se ejecuten de
manera exitosa, cumpliendo los criterios de aceptación definidos para cada uno.

 Suspensión y Reanudación
- Una característica principal tiene un error que impide probar un área importante.
- El entorno de pruebas no es lo suficientemente estable como para confiar en los
resultados.
- El entorno de pruebas es muy diferente del entorno de producción.
- No se puede instalar la nueva versión o un componente

Pruebas de Integridad de los datos y Base de datos

 Objetivo de la Verificar que los datos ingresados en las tablas de la base
Táctica: de datos no sufran.
Verificar la integridad referencial de los datos.
Táctica: Invocar cada acceso a la base de datos por medio de los
procesos y métodos definidos; enviando datos válidos e
inválidos.
Verificar que cada proceso ocurra de manera correcta y
que se retornen los datos esperados en cada caso
específico.
Herramientas Copia de Respaldo de la Base de Datos
necesarias:

Criterio de éxito: Retorno y no corrupción de los datos al exponerlos a los

procesos funcionales del sistema.
Consideraciones Probar con un mínimo de cinco registros por tabla los
Especiales: procesos.
Todos los procesos serán invocados manualmente.

PRUEBAS DE FUNCIONAMIENTO:

1. Gestión de Recursos Humanos.

2. Nómina.
3. Cargos.
4. Presupuestos.
5. Cuentas.
6. Reportes.

 Gestión de Recursos Humanos:

Registro de Personal:
 Objetivo de la Verificar que el personal adicionado a la base de datos.
Táctica:
Táctica:  Por medio del formulario de Registro de Personal
ingresar en los campos los datos solicitados y presionar
el botón de Grabar registro.
 Se enviarán datos incorrectos en los campos para
verificar que los avisos de información inválida sean
mostrados.
Herramientas Ninguna.
necesarias:
Criterio de Se revisará la tabla de Personal de la base de datos y se
éxito: verificará que el registro diligenciado en el formulario haya
sido adicionado correctamente.
En caso de enviar datos inválidos el registro no debe
haber sido adicionado a la tabla de Personal.
Consideracio Ninguna
nes
Especiales:

Búsqueda de Personal.
 Objetivo de la Verificar el registro del personal.
Táctica:
Táctica:  Por medio del formulario de Registro de Personal se
podrán buscar registros de la base de datos.
Si no se encuentran registrados avisara por medio de un
mensaje.
Criterio de éxito: En el formulario de Registro de Personal, se debe cargar
la información del registro completo encontrado.
En caso de enviar datos inválidos el motor de búsqueda
no cargará ningún registro en el formulario de Registro
de Personal.
Consideraciones Ninguna
Especiales:

Modificación de Personal.

Objetivo de la Verificar la correcta modificación el registro del personal.

Táctica:
Táctica:  Por medio del formulario de Registro de Personal se
podrán Modificar registros de la base de datos.

Criterio de éxito: En el formulario de Registro de Personal, se debe cargar

la información del registro completo encontrado.
En caso de enviar datos inválidos el motor de búsqueda
no cargará ningún registro en el formulario de Registro
de Personal.
Consideraciones Ninguna
Especiales:

Eliminación de Personal
 Objetivo de la Verificar que la eliminación de un registro del personal se
Táctica: ejecute correctamente.
Táctica:  Una vez se ubique el registro a eliminar por medio de
la función “Búsqueda de Personal” descrita
anteriormente. Se presionará el botón “Eliminar”.

Criterio de éxito: Se revisará la tabla de Registro de Personal de la base de

datos y se verificará que el registro haya sido eliminado
de la base de datos.
Consideraciones Ninguna
Especiales:

 Nómina

Objetivo de la Verificar que el proceso de nómina se lleve a cabo

Táctica: exitosamente.
Táctica:  Por medio del formulario de Generar se realizan la
nómina de personal.
 Puede ser: Quincenal, Mensual.
Criterio de éxito: Se revisará la tabla de Nomina de la base de datos y se
verificará que el registro diligenciado en el formulario haya
sido adicionado correctamente.
En caso de enviar datos inválidos el registro no debe
haber sido adicionado a la tabla de Nomina.
Consideraciones Ninguna
Especiales:

 Cargos

Registro de Cargos
 Objetivo de la Verificar que el cargo sea adicionado a la base de datos.
Táctica:
Táctica:  Por medio del formulario de Cargos ingresar en los
campos los datos solicitados y presionar el botón de
Grabar registro.
 Se enviarán datos incorrectos en los campos para
verificar que los avisos de información inválida sean
mostrados.
Criterio de Se revisará la tabla de Cargos de la base de datos y se
éxito: verificará que el registro diligenciado en el formulario haya
sido adicionado correctamente.
En caso de enviar datos inválidos el registro no debe
haber sido adicionado a la tabla de Cargos.
Consideracio Ninguna
nes
Especiales:

Búsqueda de Cargos.

Objetivo de la Verificar el registro de los cargos registrados.

Táctica:
Táctica:  Por medio del formulario de Cargos se podrán buscar
registros de la base de datos.
Si no se encuentran registrados avisara por medio de un
mensaje.
Criterio de éxito: En el formulario de Cargos, se debe cargar la información
del registro completo encontrado.
En caso de enviar datos inválidos el motor de búsqueda
no cargará ningún registro en el formulario de Cargos.
Consideraciones Ninguna
Especiales:

Modificación de Cargos.
 Objetivo de la Verificar la correcta modificación el registro del Cargo.
Táctica:
Táctica:  Por medio del formulario de Cargos se podrán
Modificar registros de la base de datos.

Criterio de éxito: En el formulario de Cargos, se debe cargar la información

del registro completo encontrado.
En caso de enviar datos inválidos el motor de búsqueda
no cargará ningún registro en el formulario de Cargos.
Consideraciones Ninguna
Especiales:

Eliminación de Cargos.

Objetivo de la Verificar que la eliminación de un registro de cargos

Táctica:
Táctica:  Una vez se ubique el registro a eliminar por medio de
la función “Búsqueda de Cargos” descrita anteriormente.
Se presionará el botón “Eliminar”.

Criterio de éxito: Se revisará la tabla de Cargos de la base de datos y se

verificará que el registro haya sido eliminado de la base
de datos.
Consideraciones Ninguna
Especiales:

 Presupuestos
 Objetivo de la Verificar que los registros de presupuesto ingresos y
Táctica: egresos se registren.
Táctica:  Por medio del formulario de Presupuesto se realizan
registros de ingresos y egresos.
 Puede ser: Mensual.
Criterio de éxito: Se revisará la tabla de Presupuesto de la base de datos y
se verificará que el registro diligenciado en el formulario
haya sido adicionado correctamente.
En caso de enviar datos inválidos el registro no debe
haber sido adicionado a la tabla de Presupuesto.
Consideraciones Ninguna
Especiales:

 Cuentas

Registro de Cuentas

Objetivo de la Verificar el registro de las cuentas de la empresa.

Táctica:
Táctica:  Por medio del formulario de Cuentas se realizan los
registros.
Criterio de éxito: Se revisará la tabla de Cuentas de la base de datos y se
verificará que el registro diligenciado en el formulario haya
sido adicionado correctamente.
En caso de enviar datos inválidos el registro no debe
haber sido adicionado a la tabla de Cuentas.
Consideraciones Ninguna
Especiales:

 Auditoria
 Objetivo de la Verificar los registros de las operaciones realizadas en la
Táctica: ejecución del software.
Táctica:  Por medio del formulario de Auditoria se podrán
visualizar los registros.
Criterio de éxito: Se revisará la tabla de Auditoria de la base de datos y se
verificará que las operaciones realizadas durante la
ejecución del software sean registradas detalladamente.
Consideraciones Ninguna
Especiales:

 Reportes

Objetivo de la Verificar que se realicen los reportes de todos los datos

Táctica: registrados en las tablas de la base de datos.
Táctica:  Por medio del formulario de Reportes se realizan los
reportes de:
- Gestión de Recursos Humanos.
- Nómina.
- Cargos.
- Presupuestos.
- Cuentas.
- Auditoria
Criterio de éxito: Consulta de los registros de las tablas.
Consideraciones Ninguna
Especiales:
 Pruebas de Control de Seguridad y Acceso.

Objetivo de la Revisar que el sistema de seguridad de la aplicación

Táctica: ofrezca un nivel confiable para la empresa.
Táctica: Se digitará la clave de acceso a la aplicación y se revisará
su desempeño.
Se tratará de ingresar por medio de datos inválidos.
Herramientas Ninguna
necesarias:
Criterio de éxito: El sistema no debe permitir por ningún motivo el ingreso
al interior a través de contraseñas incorrectas ni por
medio de trucos que violen la seguridad del aplicativo.
Consideraciones Ninguna.
Especiales:

 Pruebas de Falla y Recuperación.

Objetivo de la Probar el sistema en computadores con diferentes tipos

Táctica: de configuración de hardware para determinar su
desempeño y funcionamiento.
Táctica: Se ejecutará el sistema en tres equipos diferentes,
posteriormente se probará su rendimiento en condiciones
mínimas de hardware.
Herramientas Ninguna.
necesarias:
Criterio de éxito: Se espera obtener un desempeño no tan variable entre
máquinas, especialmente un buen comportamiento en el
computador con unos recursos de hardware por debajo
de los que tendrá la máquina donde residirá el sistema.
Consideraciones Los equipos donde se realizará la prueba tendrán grandes
Especiales: diferencias de recursos.
RESPONSABILIDADES Y EQUIPO DE TRABAJO
Personas y Roles

Contar con el personal calificado para llevar a cabo cada una de las etapas
descritas en el plan de pruebas.
RECURSOS HUMANOS
ROL RESPONSABILIDADES ESPECÍFICAS O COMENTARIOS
Administrador de  Administra el esfuerzo de las pruebas, aprueba los criterios de
Pruebas entrada y salida a las pruebas, monitorea avance del esfuerzo de
pruebas, aprueba los casos de prueba, gestiona el alcance y misión
de las pruebas, Certifica el nivel de calidad del producto construido.
Diseñador de Pruebas  Es el responsable de diseñar los set de pruebas (estructura y
enfoque) que se realizarán al sistema para una certificar que se
construyó un producto que satisface los requerimientos definidos.
Analista de Pruebas  Es el responsable de ejecutar los casos de prueba y realizar los
reportes correspondientes sobre esta ejecución.
 Realizar documentación técnica de las pruebas.

Gestión del riesgo

Algunos de los riesgos más comunes durante la fase de pruebas suelen ser:

 Falta de recursos y baja competencia en pruebas

 Falta de los recursos necesarios para ejecutar las pruebas según el plan

 Tiempo reducido asignado a la fase de pruebas

 Cambios frecuentes en la definición de los objetivos y alcance del plan de

pruebas

 Falta de coordinación entre los equipos de desarrollo y testing

 Falta de experiencia con nuevas tecnologías, herramientas, lenguajes de

programación.

Una característica muy deseable de un equipo de pruebas es la pro-actividad,

Incluso antes de que el software comience a desarrollarse, el equipo puede
involucrarse en las distintas etapas de definición para conocer más en profundidad
el proyecto así como comenzar a definir estrategias de pruebas.
Medidas a tomar para obtener los mejores resultados podrían ser:
Intervención temprana del equipo de pruebas en el proyecto

La inclusión del equipo de pruebas en las etapas iniciales del desarrollo del
producto ayudará a obtener mayor conocimiento del mismo así como permitirá
detectar posibles defectos en etapas tempranas, por lo que el coste de resolución
de los mismos será inferior.
2. Preparación de las pruebas
Antes de comenzar el desarrollo del producto, el equipo de pruebas podrá
comenzar a diseñar el plan a seguir así como identificar futuras necesidades.
Herramientas a utilizar, configuración de entornos
3. Definición de los criterios de entrada – salida
No refiriéndose a los datos, sino los puntos de unión con otras plataformas e
integraciones con terceros. Es muy útil definir y mantener las interfaces y
mecanismos de comunicación con terceros para evitar futuros problemas.
4. Requerimientos de pruebas
Desde el equipo de pruebas, se fomentará el uso de estándares, tecnologías
abiertas, así como buenas prácticas de desarrollo
5. Gestión de defectos
Una tarea de gran importancia es el seguimiento y priorización de los defectos
encontrados. Estos deben ser incluidos en los planings de siguientes iteraciones
para que sean resueltos. Además, deben ser trazados para conocer cuándo y en
qué versión han sido resueltos.
Siguiendo estos puntos, conseguiremos reducir en gran medida los riesgos más
comunes durante el desarrollo de software. Hay que tener en cuenta que se debe
trabajar en sincronía con los demás grupos implicados, desde la parte de gestión,
pasando por desarrollo, pruebas, despliegue, unos dependen de otros y los
problemas de unos se propagan a otros.