Copyright ©2009 - BizAgi

Descripción:

Se contempla la validación de la calidad de la aplicación desarrollada en la fase de construcción verificando para ello el cumplimiento con los requerimientos funcionales y técnicos especificados en la fase de diseño.

Premisas:

• La aplicación ha sido probada en la etapa de construcción. De ahí que el nivel de errores no afectará la operación del cliente.

• Se asume que se cuenta con la infraestructura física, de software y de hardware para la realización de la fase de certificación durante las fechas programadas en el cronograma del proyecto. La disponibilidad de tales recursos está asegurada por el cliente.

Objetivos:

• Garantizar la calidad de la aplicación BizAgi o los procesos a liberar a producción.

• Definir una estrategia para la elaboración y ejecución de los casos de prueba.

• Definir un plan de acción y soporte para la corrección de los problemas detectados durante las pruebas.

1.1 Definición:Consiste en la construcción y aprobación de los casos de pruebas para la certificación.

1.2 Actividades a realizar:• Elaboración matriz de requerimientos:

Inventario de actividades Inventario de requerimientos derivados por cada actividad Definir si cada prueba es positiva o negativa Describir los resultados esperados

• Elaboración de casos de prueba: Inventario de casos de prueba Definir insumos para cada caso de prueba (datos de prueba)

• Integración de matriz de requerimientos con casos de prueba Definir el conjunto de pruebas que se realizarán por cada caso de prueba

• Aprobación de Casos de Prueba Validar que los casos de prueba verifican la funcionalidad del proceso

definida en el BizAgi Spec

1.3 Premisas:

• Entender, claramente, las especificaciones y requisitos del proceso con el fin de elaborar los casos de acuerdo con la lógica del negocio.

• La elaboración de los casos de prueba es responsabilidad del Cliente.

• Se debe abarcar el mayor número de funcionalidades posibles.

1.4 Pasos a Seguir:

1.4.1 Definir Requerimientos de Prueba:

• Se registra un Requerimiento de Prueba por cada una de las figuras del flujo del proceso.

REQUERIMIENTO DE PRUEBA

R1: ¿Radicación Automática?

R2: Ingresar Datos Básicos Solicitantes

R3: Verificar la existencia del Cliente

R4:¿Al menos un solicitante No Existe?

1.4.2 Definir Requerimientos Derivados:

• Corresponden a las funcionalidades que deben ser probadas por cada uno de los requerimientos de prueba definidos en la etapa anterior.

• Códificación: reflejar el nivel del requerimiento al que pertenece y un consecutivo en orden ascendente que represente el sub-nivel.

Se debe registrar un requerimiento de prueba derivado por las diferentes condiciones de enrutamiento que se puedan presentar.

Compuerta Exclusiva

REQUERIMIENTO DE PRUEBA

REQUERIMIENTOS DE PRUEBA DERIVADOS

TIPO DE PRUEBA

R1: Radicación Automática?

R1.1 Es Radicación Automática Funcional

R1.2 No es Radicación Automática Funcional

Compuerta Inclusiva Compuerta Paralela

Se debe registrar un “requerimiento de prueba derivado”, por las condiciones de sincronización que deban ser probadas al llegar las transiciones a las figuras del proceso como Compuerta Paralela, Compuerta Exclusiva, Compuerta Inclusiva y Compuerta Compleja.

Compuerta Exclusiva Compuerta Paralela Compuerta Inclusiva Compuerta Compleja

• Para las actividades y eventos intermedios se debe incluir (si aplica) un “requerimiento de prueba derivado”, relacionadas con:

-Ayudas que debe desplegar el asistente, o descripciones.-Condiciones de asignación-Funcionalidad de reasignación-Notificaciones automáticas-Alarmas

• Se debe definir un “requerimiento de prueba derivado” para las actividades, Evento Intermedio Temporizador, subprocesos, múltiples subprocesos, relacionado con los acuerdos de servicio, especificando el tiempo.

• Por cada condición de visibilidad (campos, grupos ó tabs), obligatoriedad, editabilidad, cambio de color de la etiqueta, validaciones de condiciones, filtros, ó valores por defecto de los campos, se debe registrar un requerimiento de prueba derivado.

• Se deben registrar sub-niveles para las funcionalidades que deban ser probadas de las grillas:

-Existencia de registros-Validaciones o comportamientos de los campos de las grillas-Funcionalidad de adicionar, eliminar, editar o filtrar-Resumen en columnas

• Se debe registrar sub-niveles para las funcionalidades que deban ser probadas de los links que llevan a otras formas o pantallas.

• Se debe registrar sub-niveles para las funcionalidades que deban ser probadas de las cartas.

• Para los subprocesos y múltiples-subprocesos se deben registrar “requerimientos de pruebas derivados” relacionados con:

- Funcionalidad (integrado o no integrado).- Datos que se heredan del proceso padre al hijo.- Evaluación de condiciones para la generación del múltiple

subproceso.- Modo de salida para los múltiples – subprocesos.- Columnas personalizadas para visualizar los subprocesos y múltiple –

subproceso.

• Se debe registrar un “Requerimiento de prueba derivado” asociado con las reglas de negocio que ejecutan alguna acción.

• Se debe registrar un “Requerimiento de prueba derivado” asociado con el envío de notificaciones que son asociadas en eventos de las actividades.

• Se debe registrar sub-niveles para las funcionalidades que deban ser probadas para cada una de las Interfaces (Respuestas tipificadas de la interfaz, Resultados de la ejecución de la interfaz, Afectación a los sistemas externos)

1.4.3 Definir el enfoque de la prueba:

• Puede ser positivo o negativo:- Positivo: cuando el proceso fluye normalmente al ejecutar la acción propuesta. - Negativo: cuando el sistema al ejecutar la acción propuesta no le permite continuar al usuario con el proceso, o no lo deja ejecutar la acción.

1.4.4 Describir Resultados Esperados – Criterios de Aceptación:

• Definir el resultado de salida esperado que se comparará con el realmente obtenido, de cada uno de los requerimientos de prueba derivados.

• Se deben incluir resultados esperados a nivel de:- Enrutamiento del proceso ó Sincronizacaión- Interfaz Gráfica- Valores de Datos

Resultados Esperados a nivel de enrutamiento del proceso :

El resultado esperado consiste en describir la figura del proceso con la cual se debe continuar.

Compuerta Exclusiva Compuerta Inclusiva Compuerta Paralela

Resultados Esperados a nivel de interfaz gráfica (Visibilidad, Obligatoriedad, Editabilidad, Comportamiento de Campos, Grupos, Validación de Condiciones):

Resultados Esperados a nivel de datos:

1.4.5 Definir Casos de Prueba:Es un conjunto de alternativas que contemplan diferentes requerimientos de prueba derivados, que pueden ocurrir al ejecutar un caso.

Premisas:- No es práctico probar todos los escenarios posibles.-Seleccionar caminos importantes en el flujo que ofrezcan la seguridad de descubrir defectos.

Debe Asegurar que:• Cada requerimiento derivado se ejecute al menos una vez. • Se prueban el 100% de las funcionalidades.• Para cada transición de una figura de decisión se tenga, por lo menos

una vez un resultado verdadero, y al menos una vez, uno falso.• Cada caso debe agrupar el máximo número de requerimientos

diferentes para así reducir el total de casos.• Los puntos críticos del proceso ser probarán más de una vez.

Recomendaciones:• No es necesario que TODOS los casos de prueba contemplen ir

de inicio a fin del proceso: se pueden probar funcionalidades derivadas de uno ó varios requerimientos.

• Revisar la consistencia y complejidad del caso definido: Puede ser aconsejable fraccionar un caso en dos.

• Es posible que surgan requerimientos derivados adicionales: Complete la matriz de Requerimientos.

2.4.6 Detallar Casos de Prueba:

Tenga en cuenta que:

• Se deben organizar los “requerimientos de prueba derivados” en orden cronológico según la lógica de negocio del proceso.

• Cada caso debe contener SOLO los Requerimientos de prueba derivados que le corresponden, según la definición en la matriz de requerimientos.

• Cuando en el caso de prueba sea necesario registrar valores se deben especificar los valores de los campos que deben ser llenados por el Usuario para que se cumplan las condiciones del caso.

• Para la prueba de asignaciones, se debe especificar el nombre de los usuarios a los que le debe quedar asignada la actividad.

• Las pruebas deben realizarse con datos reales. La preparación de estos datos es responsabilidad del cliente.