1. Educación

PLAN DE CALIDAD DE PRUEBAS
Página 1 de 15
HISTORIAL DE VERSIONES Y REVISIONES
Versión
Fecha
Responsable
Descripción
Consecutivo
dd/mm/aaaa
Nombre de quien realiza las
modificaciones
Motivo por el cual se realizan las
modificaciones
Consecutivo
dd/mm/aaaa
Nombre de quien realiza las
modificaciones
Motivo por el cual se realizan las
modificaciones
Consecutivo
dd/mm/aaaa
Nombre de quien realiza las
modificaciones
Motivo por el cual se realizan las
modificaciones
Consecutivo
dd/mm/aaaa
Nombre de quien realiza las
modificaciones
Motivo por el cual se realizan las
modificaciones
Consecutivo
dd/mm/aaaa
Nombre de quien realiza las
modificaciones
Motivo por el cual se realizan las
modificaciones
1. INTRODUCCIÓN
1.1 PROPÓSITO
El propósito de este documento es planificar, estructurar y documentar las pruebas a realizar para el
proyecto Nombre proyecto, de la entidad Nombre entidad con base en la metodología definida por el
área de pruebas de la fábrica de software del Centro de Innovación y Desarrollo tecnológico - CIDT de
la Alta Consejería Distrital de TIC que se especifica en el documento Metodología de pruebas , para
validar la calidad de los productos de software, cubriendo aspectos funcionales y no funcionales.
El plan de pruebas indica los tipos y niveles de prueba que se aplicarán al proyecto, así como otros
aspectos generales del proceso de pruebas.
Con la definición del plan de pruebas se busca:
•
•
•
•
Asegurar la calidad de los productos desarrollados por la fábrica de software.
Detectar defectos en etapas tempranas del proyecto.
Disminuir la deteccón de defectos en producción.
Definir una planificación y estrategia de las pruebas a realizar en el proyecto.
1.2 REFERENCIAS
Relacionar todo los documentos de referencia aplicables, separados así:
1.2.1 Referencias externas: Se debe listar todas las referencias externas y que provienen del cliente
como: leyes, regulaciones, estándares, políticas, entre otros.
1.2.2 Referencias internas: Se debe listar todas las referencias internas a documentos, como: planes y
descripciones que complementen est plan.
PLAN DE CALIDAD DE PRUEBAS
Página 2 de 15
1.3 SUPUESTOS
Ingresar todos los supestos que se identifiquen para desarrollar este plan de pruebas:
• La aplicación debe estar correctamente instalada en el ambiente de pruebas.
• El desarrollador a ejecutado las pruebas unitarias del sistema en el ambiente de desarrollo.
• Se cuenta con la documentación actualizada y la versión sobre la cual se llevará a cabo el
proceso de pruebas.
2. DETALLE DEL PLAN DE PRUEBA
En esta sección se busca identificar los elementos que serán objeto de prueba y aquellos que serán
excluidos, incluyendo elementos de software o documentación del proyecto.
2.1 CARACTERÍSTICAS QUE SERÁN APROBADAS
La siguiente lista define las características o elementos que serán objeto de prueba y se definen como
el alcance de las pruebas:
Especificar todo lo que incluye el plan de pruebas, incluyendo si aplica:
• Áreas funcionales.
• Documentación.
• Cualquier otra característica que vaya a ser probada.
2.2 CARACTERÍSTICAS QUE NO SERÁN APROBADAS
La siguiente lista define las características o elementos que NO serán objeto de prueba y se definen
como fuera del alcance de las pruebas.
Especificar todo lo que NO incluye el plan de pruebas, incluyendo si aplica:
• Áreas funcionales que se excluyan del alcance inicial.
• Pruebas sobre aplicativos con interfaces con otros aplicativos.
• Cualquier otra característica que no vaya a ser probada.
2.3 ENFOQUE DE LAS PRUEBAS
2.3.1 Identificación nivel de pruebas. A continuación se describen diferentes niveles de pruebas que se
deben aplicar en el proyecto si algún nivel de pruebas no aplica agregar NO aplica en el nivel
correspondiente sin eliminar la descripción.
•
Pruebas Unitarias:
Las pruebas unitarias sor realizadas por el equipo de programadores y en ambiente de desarrollo;
consisten en testear el código fuente en la medida que es creado. Este nivel de prueba permite hacer
comprobaciones a los datos, la lógica y la algoritmia de los sistemas, por lo tanto se consideran
Pruebas de Caja Blanca.
PLAN DE CALIDAD DE PRUEBAS
Página 3 de 15
•
Pruebas por componentes:
Las pruebas por componentes son efectuadas en ambiente de desarrollo por los programadores
abarcando los diferentes elementos de software que estructuran los componentes, tales como las
clases, métodos, eventos, propiedades, entre otros.
•
Pruebas de Integración:
Las pruebas de integración son realizadas por el programador en ambiente de desarrollo y consisten en
probar las interfaces y las relaciones entre los componentes, por lo tanto se consideran Pruebas de
Caja Blanca y pruebas Top Down and Bottom Up.
•
Pruebas de Funcionalidad:
Las pruebas de funcionalidad son realizadas en ambiente de desarrollo por los Analistas de negocio, los
analistas de desarrollo y el Líder Funcional o quien haga sus veces. Son comunes este tipo de pruebas
con las metodologías agiles, pues constituyen el Factor Crítico de Éxito FCE en la adopción de esta
estrategia rápida. Por lo tanto las pruebas de funcionalidad deben tener como insumo indiscutible la
Especificación de requerimientos en sus diferentes sabores.
•
Pruebas de Sistemas:
Las pruebas de sistemas son realizadas en ambientes de desarrollo, pruebas y pre producción, por los
analistas de desarrollo, el Arquitecto de Software y los Líderes de Infraestructura, Bases de Datos,
Comunicaciones, entre otros. Tiene como propósito medir el desempeño de los componentes de
infraestructura, el uso de los recursos y el cubrimiento de los requerimientos en cuanto a hardware,
bases de datos, servicios, comunicaciones y seguridad, entre otros.
•
Pruebas de Aceptación:
Las pruebas de aceptación son realizadas en ambiente de pre producción y/o producción, por el
Analista de negocio, el Arquitecto Empresarial, el Líder funcional y el representante de la Dirección de
Sistemas de las Entidades Distritales. Tienen como propósito establecer el grado de cumplimientos de
las Especificaciones Funcionales.
•
Pruebas de Instalación:
Las pruebas de instalación son realizadas en los diferentes ambientes y con la oportunidad requerida,
estas pruebas están relacionadas con el despliegue de los componentes del sistema y deben seguir los
guiones propuestos en los manuales de Explotación. Por lo general las realizan los ingenieros de
soporte, el Arquitecto de Software, los líderes de infraestructura, bases de datos y comunicaciones.
2.3.2 Identificación de los tipos de pruebas. A continuación se describen los tipos de pruebas que serán
aplicados en el proyecto: si algún nivel de pruebas no aplica agregar NO aplica en el tipo
PLAN DE CALIDAD DE PRUEBAS
Página 4 de 15
correspondiente sin eliminar la descripción.
•
Pruebas de Facilidad:
Consisten en medir el grado en el que los usuarios interactúan con las interfaces gráficas para realizar
las operaciones propias de la misionalidad de las Entidades Distritales; es decir que facilitan la labor del
día a día de los funcionarios del Distrito.
•
Pruebas de Volumen:
Consisten en medir el grado en el que las bases de datos, aplicaciones y los componentes responden
ante la demanda de altos volúmenes de información, que Esenciales fluye desde y hacia adentro de los
sistemas de información, sus las funcionalidades y servicios.
•
Pruebas de Stress:
Consisten en medir el grado en el que el software, las páginas web y los servicios web responden ante
la carga de transacciones en un entorno controlado, simulando los perfiles de usuarios más habituales
para determinar la capacidad máxima de usuarios concurrentes, lo cual ayudara a elaborar planes de
negocio y dimensionar correctamente la plataforma.
•
Pruebas de Usabilidad:
Consisten en medir el grado en el que el software, y las páginas web permiten hacer uso de manera
eficiente de las funcionalidades y la navegabilidad, sin olvidarse de aspectos como la ergonomía y la
productividad.
•
Pruebas de Seguridad:
Consisten en medir el grado en el que el software protege la información sensible de las Entidades
distritales; permite establecer en los puntos de mayor vulnerabilidad la efectividad de los controles y
mecanismos de protección integrados en los sistemas de información.
• Pruebas de Desempeño:
Consisten en medir el grado en el que el software responde eficientemente al uso de los recursos de
memoria, procesador, comunicaciones, y almacenamiento en los tiempos, ciclos y cantidades previstas
en los ANS de cada elemento, componente o servicio, solo o integrado para hacer parte de sistemas de
información más complejos. Estas pruebas permiten medir la instrumentación del Software y la
identificación de eventos que podrían degradar el desempeño del software.
•
Pruebas de Configuración:
Consisten en medir el grado en el que el software puede integrarse o acoplarse, así como también el
PLAN DE CALIDAD DE PRUEBAS
Página 5 de 15
nivel de reusabilidad de los componentes de software. Permite establecer la complejidad en la
asignación de valores a los parámetros que promueven la transversalidad de los componentes.
•
Pruebas de Fiabilidad:
Consisten en medir el grado en el que el software brinda los servicios y buen funcionamiento sin recurrir
a intervenciones para darle mantenimiento correctivo y adaptativo; generalmente asociado con el
tiempo sin fallos y la probabilidad de buen funcionamiento.
•
Pruebas de Recuperación:
Consisten en medir el grado en el que el software permite reestablecer su operación después de
detectar fallas o inconsistencias; permite medir el nivel de complejidad en la recuperación de la data
para dejar los sistemas totalmente operativos.
•
Pruebas de Documentación:
Consisten en medir el grado en el que el software está debidamente documentado, con las
actualizaciones en la totalidad de los artefactos técnicos, operativos y administrativos, teniendo en
cuenta los estándares de documentación propuestos por el CIDT y en concordancia a los Sistemas de
Gestión de Calidad.
2.3.3 Definición de la estrategia: En este módulo se define las rondas que serán ejecutadas en el
proyecto, así como la gestión de los defectos.
Ronda 1: Ejecución de los casos de prueba definidos en la primera versión recibida.
Ronda 2: En esta actividad se revisa las correcciones realizadas sobre los problemas o defectos en que
se hayan reportado durante la ejecución de la Ronda 1.
Ingresar más rondas si es necesario.
Regresión: En esta actividad se revisa que los errores que se hayan reportado y corregido, no hayan
afectado las funcionalidades que venían comportándose correctamente, validando que no se repliquen
los errores y todo el aplicativo funciona óptimamente.
2.3.3.1 Estrategia respecto a la gestión de defectos: <<Modificar la estrategia descrita en este numeral
si es diferente a la que se plantea en el proyecto >>
Los defectos encontrados durante la ejecución de las pruebas serán registrados en la herramienta
descrita en el numeral “Herramientas de apoyo en el proceso de pruebas”. Los pasos que se realizan
para la gestión de los defectos encontrados son:
PLAN DE CALIDAD DE PRUEBAS
Página 6 de 15
Los defectos son gestionados a través de los siguientes estados:
<<Si no se utiliza Mantis, definir el estado de los defectos de la herramienta correspondiente>>
2.3.3.2 Reglas para la clasificación de defectos
•
Naturaleza
Categoría
Descripción general
Ambiente
Se manifiesta en el momento que el ambiente de pruebas esté funcionando
incorrectamente, o el sistema está mal configurado o parametrizado.
Datos
Se manifiesta cuando los datos existentes no están de acuerdo a la
estructura definida para el buen funcionamiento del software.
Documentación
Se manifiesta cuando la documentación está mal definida o existe
ambigüedad.
PLAN DE CALIDAD DE PRUEBAS
Página 7 de 15
Funcionalidad
Se manifiesta cuando el funcionamiento del software no está de acuerdo con
las especificaciones y requisitos del mismo.
Hardware
Se manifiesta cuando existe algún problema en la parte del hardware del
sistema. Fallas en los periféricos o herramientas utilizadas para la ejecución
de pruebas
Utilidad
Se presenta cuando se genera un incumplimiento de los requisitos de
fiabilidad, mantenimiento, o capacidad de soporte (por ejemplo, diseño
complejo, código indocumentado, el registro de errores ambigua o
incompleta, etc.).
Presentación
Se manifiesta cuando el software no cumple con los requisitos mínimos de
lineamientos gráficos.
Rendimiento
Se manifiesta cuando el desempeño del sistema es muy bajo, de acuerdo a
los requisitos no funcionales.
Seguridad
Se manifiesta por la gestión de la seguridad de la funcionalidad, no está
controlada ni alineada con los requisitos del negocio o establecidas en la
documentación.
Tipo de incidencia
•
Categoría
Descripción general
Defecto
Una imperfección o deficiencia en un producto de trabajo donde ese producto
de trabajo no cumple con sus requisitos o especificaciones y necesita ser
reparado o sustituido.
Mejora
Es una propuesta para mejorar alguna funcionalidad o parte del producto de
software por parte del Analista de Pruebas.
Sugerencia
Es una propuesta para mejorar alguna funcionalidad o parte del producto de
software por parte de la Entidad.
Severidad
•
Categoría
Descripción general
Stopper/Bloqueante
La prueba se inhibe o suspende hasta la corrección o la identificación de la
solución adecuada.
Crítico
Operaciones principales son inevitablemente
comprometida la seguridad.
Mayor
Operaciones principales se ven afectadas pero se puede continuar.
Menor
Operaciones no principales se ven interrumpidas.
Inconsecuente
No se genera un impacto significativo en la operación.
interrumpidas y se
ve
PLAN DE CALIDAD DE PRUEBAS
Página 8 de 15
•
Prioridad
Categoría
Descripción general
Alta
Los defectos son prioridad para el análisis y solución.
Media
Estos defectos se encuentran en la cola luego de los defectos altos para su
análisis y solución.
Baja
Estos defectos se encuentran al final de la cola para su análisis y solución.
La clasificación anterior puede variar de acuerdo con la herramienta implementada y los ajustes que en
ella se puedan realizar para cada categoría.
2.4 CRITERIOS GENERALES
2.4.1 Criterios de aprobación de una aplicación: Los criterios de aprobación de una aplicación definen la
aceptación de la ejecución y validación del proceso de prueba. Una vez se cumpla con los criterios
que se listan a continuación, se iniciará el proceso para realizar el despliegue en el ambiente preproductivo del cliente.
•
•
•
•
Se ha ejecutado el <<100%>> de los casos de prueba diseñados para este proyecto y el
resultado del <<100%>> de los casos ha sido exitoso.
Para el punto anterior si se presentan casos de prueba fallidos, éstos no deben tener
relacionados defectos con severidad alta.
El <<100%>> de los defectos detectados en la ejecución de pruebas han sido solucionados y
se ha validado dicha solución por parte de pruebas.
Cuando, a pesar de no cumplirse en su totalidad el punto anterior, el coordinador manifieste
(mediante formato escrito) que los defectos no son críticos para entregar al cliente (los defectos
pasarían a un estado de “Próxima Versión”).
2.4.2 Criterios de suspensión y requisitos de reanudación de las pruebas: El equipo de pruebas puede
suspender las pruebas si se presenta algún motivo ajeno que impida la realización de las pruebas de
forma fluida para esto, debe informar al coordinador la causa o causas específicas de la suspensión.
Las causas que ocasionarán la suspensión del proceso de prueba serán las siguientes:
•
•
•
•
•
Cuando más del <<20%>> de los defectos son reabiertos entre ciclos de pruebas.
Cuando el ambiente de pruebas no se encuentre disponible o cuando éste presente algún
inconveniente.
Problemas de desempeño de la máquina donde se encuentra el producto que dificulten la
operación de la prueba.
No disponibilidad del Set de datos para las pruebas si este está definido.
Cambios considerables realizados a la aplicación.
Para reanudar formalmente el proceso de pruebas, el equipo de desarrollo debe informar al equipo de
PLAN DE CALIDAD DE PRUEBAS
Página 9 de 15
pruebas por escrito, que los inconvenientes que impedían la realización de las pruebas han sido
solucionados y que es posible iniciar nuevamente las pruebas.
2.5 ENTREGABLES DE PRUEBA
Los entregables producidos durante el proceso de pruebas para el proyecto son:
Nombre del documento
Propósito
Plan de Pruebas
Contiene todo el modelo de pruebas a seguir en el proyecto.
Estimación de Tiempos
Se realiza con el fin de tener un estimado del tiempo que se requiere
para el desarrollo del proceso de pruebas en el proyecto.
Lista de chequeo funcional Permite identificar si los documentos funcionales fueron construidos de
acuerdo a los parámetros definidos en la lista de chequeo.
Diseño de
Pruebas
Casos
de Contiene diseño detallado de cada uno de los casos de prueba del
proyecto.
Actas de Reunión
apoyo de memoria
y/o Cada vez que se realice una reunión, se realizará un acta de reunión y/o
ayuda de memoria así como la lista de asistencia y de esta manera
tener consignados los compromisos y las conclusiones y decisiones
tomadas en la reunión.
Informe de pruebas
Este informe es entregado para tener un control del avance de las
pruebas, que porcentaje de pruebas se han cubierto, cuantos errores
han sido generados, en un periodo determinado de tiempo.
3. ADMINISTRACIÓN DE LAS PRUEBAS
3.1 AMBIENTE / INFRAESTRUCTURA
3.1.1 Ambientes para el desarrollo de las pruebas: A continuación se describen los diferentes ambientes
de prueba que se deben tener disponibles para el proyecto y las necesidades de cada uno de ellos <<Si
alguno de los ambientes no aplica, colocar No aplica)>>.
•
Ambiente local (ambiente de desarrollo)
En este ambiente se realizan las pruebas unitarias por parte de los desarrolladores, las características
de este ambiente deben ser:
Estas pruebas deben ser realizadas antes de liberar versiones en el ambiente de pruebas interno
(pruebas CIDT) para pruebas internas de la fábrica.
•
Ambiente pruebas interno (pruebas CIDT)
En este ambiente se realizan las pruebas internas por parte de las personas asignadas a las pruebas
de la solución por parte de la fábrica.
PLAN DE CALIDAD DE PRUEBAS
Página 10 de 15
Para ejecutar las pruebas en este ambiente se deben diseñar los casos de prueba que se requieran
para los casos de uso que se van a probar. El diseño de casos de prueba se realizará teniendo en
cuenta la aplicación <<Colocar la aplicación o plantilla a utilizar TestLink>>.
•
Ambiente de pruebas de la Entidad
Cuando la solución ha terminado su construcción se inician las pruebas en el ambiente de
preproducción, las cuales se realizan en dos fases, la fase 1 para que la fábrica realice una revisión
final de calidad antes de liberar la versión final a pruebas por parte de la Entidad y la fase 2 donde la
fábrica verifica que la versión e encuentra correctamente instalada y notifica a la Entidad/GEL que se
puede dar inicio a las pruebas que ellos realizan, teniendo en cuenta lo que se indica a continuación
para cada una de las fases.
•
Ambiente de Producción
El equipo de pruebas de la fábrica realiza una verificación rápida para asegurar que la versión se
encuentra bien instalada antes de iniciar las pruebas que realizará en este ambiente.
Las pruebas en este ambiente por parte de la fábrica se iniciarán una vez se instale la versión en el
ambiente de Producción.
<<Si no se realizan pruebas en el ambiente de Producción indicar el motivo por el cual no se realizarán
pruebas en este ambiente>>.
3.1.2 Hardware: A continuación se definen los requerimientos de hardware que son necesarios en los
diferentes ambientes para el desarrollo de las pruebas:
Recursos del sistema
Recurso
Cantidad
Características
Memoria:
PC
1
Procesador:
Sistema Operativo:
Nombre:
Servidor de aplicaciones
1
Aplicativo:
<<Configuración: Si se tiene esta información>>
<<Memoria: Si se tiene esta información>>
Nombre:
Servidor base de datos
1
Características:
3.1.3 Software: A continuación se definen los requerimientos de software que son necesarios en los
PLAN DE CALIDAD DE PRUEBAS
Página 11 de 15
diferentes ambientes para el desarrollo de las pruebas:
<< Adicionar software necesario>>
3.1.4 Herramientas de apoyo en el proceso de pruebas: <<Describir las herramientas que sirven de
apoyo al proceso de pruebas como son: administrador de defectos, administrador de casos de prueba,
automatización de pruebas, entre otros >>.
Herramienta
Descripción general
3.1.5 Datos y parámetros:
3.1.5.1 Respecto a la ejecución: En este punto se deben listar todas las necesidades relacionadas con
los Datos y parámetros de la aplicación:
•
•
¿Quién se encarga de la adecuación de datos en el ambiente de pruebas?
¿Cómo se hace la parametrización? Y quien la realiza?
3.1.5.2 Respecto a la Entidad: Indicar quien es el encargado de entregar el set datos para ejecutar las
pruebas.
•
En caso que sea la Entidad entregue el set de datos relacionar el siguiente párrafo:
El set de datos para ejecutar las pruebas lo provee la Entidad y tiene las siguientes características:
están verificados, completos (cubre totas las pruebas a relizar), son consistentes con el desarrollo del
proyecto y no requieren ningún tipo de manipulación.
•
En caso que la Entidad no entregue el set de datos:
La creación de datos se realizará durante la ejecución de las pruebad y dependen del caso de prueba a
ejecutar.
3.1.6 Responsabilidades y autoridades:
3.1.6.1 Plan de comunicación: <<Si hay un plan de comunicación para el proyecto, relacionar el nombre
en este capítulo, de lo contrario definir el plan de comunicación del proyecto>>.
3.1.6.2 Roles y responsabilidades: A continuación se nombran las actividades en las cuales interactúan
los diferentes roles (relacionar este ítem sólo si no se hace la especificación en el plan de
comunicación):
PLAN DE CALIDAD DE PRUEBAS
Página 12 de 15
Rol / recurso
Responsabilidades
Coordinador del proyecto
Líder de pruebas
Analista de pruebas
Líder de desarrollo
Líder de requerimientos
Líder del proyecto
3.1.6.3 Recursos humanos:
Nombre completo
Rol
Organización
<<Adicionar los nombres de las personas y roles necesarios involucrados en el proyecto>>.
3.1.7 Estimación del proceso de pruebas: En este ítem se relaciona la estimación de tiempos del
proceso de pruebas del proyecto Nombre Proyecto el cual contiene las actividades para cada una de
sus fases, el tiempo estimado y las fechas inicial y final para la realización de las pruebas.
Relacionar la estimación definida en la plantilla de estimación.
3.1.8 Riesgo y contingencia: <<Agregar, modificar o eliminar los Riesgos del proyecto que apliquen al
proyecto >>.
Risk No.
1
Descripción
del riesgo
El
ambiente
de pruebas no
se encuentra
disponible en
el
tiempo
requerido
según el plan
de trabajo.
La
no
Entidad
aprueba
Probabilidad
Impacto
Causas
posibles
Consecuencia
El inicio de las
pruebas
se
retrasará
impactando
el
tiempo
del
proyecto y el
plan de trabajo.
No será posible
cumplir con las
Calificación
del control
PLAN DE CALIDAD DE PRUEBAS
Página 13 de 15
2
3
4
los
entregables
de acuerdo
al plan de
trabajo.
fechas
planeadas
Si
los
cambios a la
documentaci
ón
del
proyecto,
código
fuente,
hardware o
software no
son
formalmente
comunicados
al área de
pruebas
Los casos de
prueba pueden
ser incorrectos
y por lo tanto
los resultados
de las pruebas
pueden
ser
inválidos.
Si
el
ambiente
provisto para
la ejecución
de
las
pruebas
funcionales
de sistema
no es un
ambiente
independient
e para esta
fase.
Los resultados
de los casos de
prueba pueden
ser incorrectos
y por lo tanto
los resultados
de las pruebas
pueden
ser
inválidos.
5
Probabilidad
Impacto
Muy alta
5
Catastrófico
5
Alta
4
Grave
4
Media
3
Medio
3
Baja
2
Bajo
2
Muy baja
1
Muy bajo
1
4. GENERAL
4.1 SEGUIMIENTO
Durante el proceso de pruebas, se realizarán <<N>> reuniones de seguimiento. En estas reuniones, se
PLAN DE CALIDAD DE PRUEBAS
Página 14 de 15
tratarán como mínimo los siguientes temas:
•
•
•
•
•
Seguimiento de incidencias reportadas.
Seguimiento de cambios y mejoras.
Análisis y solución de problemas o situaciones que afectan el proceso de pruebas.
Tiempos en los cuales ENTIDAD recibirá la corrección de los defectos por parte del grupo de
desarrollo.
Seguimiento a los riesgos del proyecto.
4.2 ACUERDOS
A continuación se definirán una serie de acuerdos entre la Entidad y la fábrica de software respecto a
varios aspectos a tener en cuenta durante los procesos de pruebas, tanto para evaluar la calidad de las
pruebas como para dejar claros tiempos de atención y respuesta.
4.2.1 Compromisos por parte de la Entidad:
Revisión y aprobación del plan de pruebas:
•
Es el tiempo que <<Entidad>> se tarda para revisión y aprobación del plan de pruebas desde el
momento de la entrega por parte del analista de Calidad.
• Valor Objetivo: <<2>> días.
Revisión de los casos de pruebas de aceptación de usuario
•
•
Es el tiempo que <<Entidad>> se tarda para revisión de los casos de prueba diseñados desde
el momento de la entrega por parte del analista de Calidad
Valor Objetivo: <<5>> días
4.3 PLAN DE ASEGURAMIENTO DE LA CALIDAD
4.3.1 Revisión por parte del líder de proyecto y líder de pruebas: Las Revisiones por parte del líder de
proyecto y líder de pruebas tienen como propósito garantizar el cumplimiento de la metodología de
pruebas y contribuir a asegurar la calidad de los productos de trabajo que se generan en la ejecución
del proyecto, de esta manera, contribuir a la satisfacción del cliente en cuanto al cumplimiento de los
requisitos, el cumplimiento de las políticas organizacionales y el cumplimiento de los objetivos de
calidad del proyecto.
El líder de pruebas realizará una revisión a los entregables generados por el equipo de pruebas y
posteriormente el líder de proyecto realizará su revisión correspondiente, antes de ser enviados a la
Entidad para su revisión y aprobación, entre ellos se encuentra: plan de pruebas e informes de
ejecución.
4.3.2 Revisión de pares: La Revisión de Pares tiene como propósito, la detección temprana de errores
para disminuir la propagación de errores en etapas posteriores. Estas revisiones serán realizadas entre
<<los analistas de pruebas y líder de pruebas ó entre analistas de pruebas>> a los siguientes
artefactos:
PLAN DE CALIDAD DE PRUEBAS
Página 15 de 15
Artefacto
Casos de prueba
Par Revisor
Profundidad
<<Analista de pruebas o Revisión Técnica
líder de pruebas>>
Frecuencia
Al final del diseño de
casos de prueba
4.4 PLAN DE GESTIÓN DE LA CONFIGURACIÓN
4.4.1 Nombramiento: <<Si existe un plan de confiuración indicar el nombre del documento y sección
para el nombramiento de los artefactos de pruebas, de lo contrario indicar el nombramiento que se
definirá para el proyecto>>.
4.4.2 Repositorio centralizado: La información del proyecto se ubicará en XXXX, el cual se encuentra en
la ruta: <<especificar ruta>>.
4.4.3 Generación líneas base: Se realizará una línea base una vez se finalice la etapa de diseño de los
casos de prueba tomando copia de la información recopilada hasta ese momento en el repositorio del
proyecto y dejando dicha copia en el directorio del repositorio destinado para esta actividad.
4.4.4 Plan de administración de datos: Con el fin de controlar la documentación recibida por parte de la
Entidad se emplea el documento XXXXX, en el cual se registra la información de control y gestión
necesaria para esta documentación.
5. GLOSARIO
<<Definir los términos, acrónimos y abreviaturas manejados en este documento y que podrían causar
confusión o que podrían no tener una definición clara para los participantes del proyecto>>.
Caso de prueba: conjunto de condiciones o variables, bajo las cuáles el analista determinará si el
requisito de una aplicación es parcial o completamente satisfactorio.
CIDT: Centro de innovación y desarrollo tecnológico.
Entidad: entidad para a cual se desarrolla una aplicación.
Fábrica de software: Línea de producción de software.
<<Incluir y/o quitar los términos que apliquen para el documento y dejarlos en orden alfabético>>.