0% encontró este documento útil (0 votos)
9 vistas13 páginas

Flujo de Trabajo para Pruebas de Software

conceptos de prueba
Derechos de autor
© All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
9 vistas13 páginas

Flujo de Trabajo para Pruebas de Software

conceptos de prueba
Derechos de autor
© All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd

PRU

INSTRUCCIONES: a continuación se describe el flujo de trabajo correspondiente al área de


procesos de PRUEBAS para el desarrollo de software, en el cual se debe apoyar para la
ejecución de sus actividades; elaborado la documentación descrita en el procedimiento; debe
actualizarla en el repositorio de la documentación asignado para el proyecto. Se recomienda:

• Leer los objetivos y Alcance


• Seguir cada uno de los pasos descritos. Por lo general se muestra un diagrama
seguido de sus respectivos incisos.
• Elaborar la documentación indicada o la que se aplique al proyecto.

NOTA:
Las frases escritas en Celeste indican documentación que puede llenar y descargar al dar
click, también encontrará información relevante para la comprensión de la actividad.
Al finalizar existe una sección con material de apoyo que puede usar para mejorar el
procedimiento y enriquecer la información del proyecto.

Fundamento Institucional
Éste procedimiento fue avalado por el sistema de gestión de calidad del Ministerio de Finanza
Públicas denominado también como SGC y aprobado por las autoridades correspondientes
del área.

Objetivos
El Procedimiento de Pruebas incluye las actividades para realizar las pruebas a los sistemas,
estableciendo la metodología de trabajo para el equipo de pruebas de software. Las
actividades incluyen tres etapas de pruebas mínimas para minimizar riesgos por errores de
desarrollo, y garantizar una cobertura apropiada de escenarios y condiciones de pruebas que
garanticen un alto nivel de calidad.

Alcance
El procedimiento está orientado a los equipos de La Dirección de Tecnologías de la
Información (DTI), que intervienen en el diseño y desarrollo de sistemas, y particularmente al
grupo de personas que realizan actividades de Pruebas de Sistemas.
El procedimiento actual se enfoca en el flujo del área de proceso de pruebas y las etapas
incluidas son:

• Planificar Pruebas
• Diseñar Pruebas
• Ejecutar Pruebas
• Analizar Resultados de Pruebas

Procedimiento

Planificar Pruebas
1. Inicio

En ésta fase inicia el proceso

2. Revisar Requerimientos y Diseño

El Administrador de Pruebas revisa la documentación de requerimientos para


comprender la funcionalidad solicitada, así como la documentación de diseño para
conocer el análisis de impacto. Por la importancia de construir con base en
requerimientos, es necesario que el Analista de Pruebas haga lo mismo. Esto facilitará
el entendimiento de lo que se espera. Si tienen consultas, deberán plantearlas en un
documento para control de consultas.

Documento Entrada Se pueden basar en el documento de Visión, las Especificaciones


complementarias y la especificación de los Casos de Uso
Documento Salida REQ-08-Registro de Consultas y Respuestas
Herramienta No hay herramienta específica

3. Consultas

SI: Continuar en Paso 4


NO: Continuar en Paso 6

4. Resolver Consultas

El Analista de Requerimientos presentará las respuestas necesarias. Si él no puede


contestar, investiga con los usuarios y otros participantes (stakeholder), dependiendo
de la naturaleza de las preguntas realizadas.

Documento Entrada REQ-08-Registro de Consultas y Respuestas Enviado por el


Administrador de pruebas o el Analista de Pruebas
Documento Salida REQ-08-Registro de Consultas y Respuestas Resuelto
Herramienta No hay herramienta específica

5. Consultas Resueltas?

SI: Continuar en Paso 6


NO: Regresa a Paso 4
6. Definir Misión de Pruebas

El Administrador de Pruebas determina la misión, con base en las expectativas y


resultado esperado de acuerdo a los requerimientos.

Documento Entrada No hay un documento específico


Documento Salida PRU-01-Plan de Pruebas Maestro
Herramienta No hay herramienta específica

7. Identificar Suites de Prueba

El Analista de Pruebas determina si se pueden agrupar casos de prueba para armar


flujos de negocio completos, que permitan realizar pruebas en forma integrada.
Cuando se desea probar un aplicativo completo, o alguna funcionalidad que afecta
otros sistemas, es necesario obtener retroalimentación de los participantes
(stakeholders) para considerar pruebas integrales.

Documento Entrada No hay un documento específico


Documento Salida PRU-01-Plan de Pruebas Maestro en la sección de suites de
pruebas
Herramienta No hay herramienta específica

8. Identificar Casos de Prueba

El Analista de Pruebas inicia la identificación y descripción de los diferentes escenarios


de prueba. Puede hacer un listado donde se indiquen los módulos, secciones,
formularios,reportes o cualquier otro producto a probar.

9. Establecer Recursos de Pruebas

El Administrador de Pruebas establece recursos con base en la lista de escenarios y la


identificación de objetos sujetos a prueba. Los recursos incluyen personas y
necesidades de hardware y software para realizar las pruebas.

Documento Entrada No hay un documento específico


Documento Salida PRU-01-Plan de Pruebas Maestro en la sección de Objetos de
Pruebas, Necesidades de ambiente y Responsabilidades
Herramienta No hay herramienta específica
10. Definir Calendario de Pruebas

En una etapa inicial del proyecto, el Administrador de Pruebas determina fechas clave
y establece calendario de pruebas. Entrega esta información al Administrador de
Proyectos para la consideración del plan general de desarrollo. Al retomar sus
actividades de pruebas confirma las fechas proporcionadas al inicio y modifica lo que
sea necesario para actualizar el plan.

Documento Entrada No hay un documento específico


Documento Salida PRU-01-Plan de Pruebas Maestro en la sección de Metas Clave
de pruebas
Herramienta No hay herramienta específica

11. Definir Métricas de Calidad

El Administrador de Pruebas, establece las métricas de calidad que brindarán


información como soporte para decisiones. Estas métricas se basan en un plan
general de métricas, sin embargo, cada proyecto puede definir algunas específicas. En
el caso de la cartera de mantenimientos, se basa en un conjunto de métricas que
permitan la visualización de comportamiento, estabilidad o volatilidad de aplicativos
con reportes frecuentes de defectos.

Documento Entrada No hay un documento específico. Se pueden validar las Políticas


de Calidad para Desarrollo Interno
Documento Salida PRU-01-Plan Master de Pruebas en la sección de Métricas de
Calidad y Pruebas
Herramienta No hay herramienta específica
Diseñar Pruebas
12. Elaborar Guiones de Pruebas (también llamados Casos de Prueba o Script de
Prueba)

El Analista de prueba realiza la documentación de guiones para cada caso de prueba,


definiendo pasos y puntos de verificación de acuerdo a lo establecido en los
requerimientos. Cuando se tiene un ambiente automatizado de pruebas. Se requiere
del apoyo del Diseñador de Pruebas, para crear o actualizar guiones automatizados.
También debe considerar elementos técnicos que requieran pruebas con base en el
diseño de solución.

Documento Entrada PRU-01-Plan Maestro de Pruebas


Documento Salida PRU-02-Plan de Pruebas Detallado
Herramienta No hay herramienta específica

13. Dudas?

SI: Continuar en Paso 14


NO: Continuar en Paso 17

14. Plantear Consultas

El Administrador de las Pruebas siempre será el contacto con otros equipos. Él es el


encargado de recopilar las preguntas, incluyendo las de él mismo. Presenta el
documento de Consultas y Respuestas al Analista de Requerimientos.

15. Resolver Consultas

El Analista de Requerimientos presentará las respuestas necesarias. Si él no puede


contestar, investiga con los usuarios y otros participantes (stakeholderes),
dependiendo de la naturaleza de las preguntas.

16. ¿Dudas Resueltas?

SI. Continuar en Paso 17


NO. Regresar al Paso 14
17. Actualizar Calendario de Pruebas

El Administrador de Pruebas revisa avance con el equipo, y con base en el detalle


generado, actualiza el calendario, si es necesario. El establece las metas clave, y las
envía al Administrador del Proyecto, quien maneja el plan general de desarrollo.

18. Elaborar/Actualizar Plan Maestro de Pruebas

Una vez identificados los escenarios de pruebas y el calendario, el Administrador


procede a Completar el Plan Master de Pruebas. Si en algún momento previo, ha
iniciado este documento, debe actualizar la información, ya que es en este punto en el
cual se tiene mayor claridad de las actividades y recursos requeridos para las pruebas.

Ejecutar Pruebas
19. Ejecutar Pruebas Unitarias

El Desarrollador ejecuta sus pruebas unitarias. Registra los hallazgos, corrige


defectos, ejecuta nuevamente y actualiza los resultados de las pruebas.

20. Evidencia Prueba Unitaria?

SI: Continuar en Paso 21


NO: Regresar al Paso 19

21. Aplican Pruebas de Integración?

SI: Continuar en el Paso 22


NO: Continuar en el Paso 27

22. Ejecutar Guiones de Pruebas de Integración

El Probador ejecuta las pruebas diseñadas completando cada uno de los guiones de
prueba y dejando evidencia de errores en el formato correspondiente.

Documento Entrada PRU-02-Plan de Pruebas Detallado


Documento Salida PRU-02-Plan de Pruebas Detallado completado, PRU-04-Reporte
de Errores para evidencia de errores
Herramienta No hay herramienta específica

23. Generar Bitácora de Pruebas de Integración

El Probador se asegura de completar la Bitácora (en los guiones de pruebas) con las
anotaciones pertinentes, así como la descripción de errores detectados durante la
prueba.

24. Generar Reporte de Pruebas de Integración

El Administrador de las Pruebas, presenta el informe de las bitácoras con los


resultados de la ejecución de las pruebas. Lo presenta y publica para todo el equipo
del proyecto o mantenimiento. Se notifica especialmente al Administrador del proyecto,
para asignar al desarrollador que corrige defectos.
Documento Entrada PRU-04-Reporte de Errores, PRU-02-Plan detallado de pruebas
(completado o con el avance al momento)
Documento Salida PRU-05-Avance de Ejecución de Pruebas
Herramienta No hay herramienta específica

25. Se reportan defectos?

SI: Continuar en el Paso 26


NO: Continuar en el Paso 27

26. Corregir Defectos de Pruebas de Integración

El desarrollador asignado corrige los defectos. Debe repetir el ciclo y regresar al Paso
19.

27. Aplican Pruebas de Aceptación de Usuario?

SI. Continuar en el Paso 28


NO. Continuar en el Paso 33

28. Ejecutar Guiones de Pruebas de Aceptación de Usuario

Se le entrega al usuario certificador el formato de Reporte de errores para que anote


sus hallazgos. El Usuario certificador ejecuta las pruebas. Se pueden también hacer
cambios con los desarrolladores presentes para depurar en el momento de pruebas la
aplicación.

Documento Entrada No hay un documento específico


Documento Salida PRU-04-Reporte de errores
Herramienta No hay herramienta específica

29. Generar Bitácora de Pruebas de Aceptación de Usuario

El Usuario Certificador se asegura de completar la Bitácora con las anotaciones


pertinentes, así como la descripción de errores detectados durante la prueba.
30. Generar Reporte de Pruebas de Aceptación de Usuario

El Administrador de las Pruebas, debe presentar el informe de las bitácoras con los
resultados de la ejecución de las pruebas. Lo presenta y publica para todo el equipo
del proyecto o mantenimiento. Se notifica especialmente al Administrador del proyecto,
para asignar al desarrollador que corrige defectos.

Documento Entrada PRU-04-Reporte de Errores, PRU-02-Plan detallado de pruebas


(completado o con el avance al momento)
Documento Salida PRU-05-Avance de Ejecución de Pruebas
Herramienta No hay herramienta específica

31. Se reportan defectos?

SI: Continuar en el Paso 32


NO: Continuar en el paso 33

32. Corregir Defectos de Pruebas de Aceptación de Usuario

El desarrollador asignado corrige los defectos. Debe repetir el ciclo y regresar al Paso
19.
Analizar Resultado de Pruebas

33. Notificar Certificación de Pruebas

El Administrador de pruebas es responsable de notificar la certificación de pruebas. En


caso de no haber ejecutado pruebas de integración y/o Aceptación de Usuario, debe
indicarlo en el documento de certificación y debe generar el documento de aceptación
de cambios sin pruebas en el cual se incluye la justificación debida.
Documento Entrada PRU-05-Avance de Ejecuciónde Pruebas
Documento Salida PRU-07-Documento de Certificación de Aplicaciones o PRU-06-
Aceptación de Cambios sin Pruebas de Usuario
Herramienta No hay herramienta específica

34. Actualizar Matriz de Trazabilidad

Se descarga el documento REQ-07-Matriz de Trazabilidad del repositorio del


proyecto en el área de proceso de REQUERIMIENTOS la cual contiene las fases de
REQ y A&D llenas. Se agregan los nombres de los Casos de Prueba (CP) y su
relación con los demás componentes para completar la fase de PRU. Al actualizar
dicha matriz se sube al área de procesos correspondiente.

35. Elaborar/Analizar Métricas de Calidad

El Administrador actualiza la información de calidad con los resultados del reporte de


defectos. Esto le permite generar y/o visualizar las métricas de calidad establecidas.

36. Analizar Riesgos de Calidad

El Administrador de Pruebas puede detectar riesgos que afecten el resultado esperado


de las pruebas. Pueden ser aspectos técnicos, de personal de apoyo, temas legales o
de presupuesto. Por lo que debe preparar medidas para la siguiente implementación
de la fase de Pruebas.

37. Generar Informe de Avance en Pruebas

El Administrador de Pruebas, prepara la información para generar el reporte de avance


de las pruebas, con la el resumen de cobertura de pruebas y estatus de defectos
reportados, incluyendo gráficas y métricas de calidad.

También podría gustarte