BizAgi - Business Agility

Presentación del tema: "BizAgi - Business Agility"— Transcripción de la presentación:

1 BizAgi - Business Agility
Metodología certificación proyectos BizAgi

2 FASE DE CERTIFICACION 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.

3 OBJETIVOS FASE DE CERTIFICACION
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.

4 DISEÑO- FASE DE CERTIFICACION
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

5 DISEÑO- FASE DE CERTIFICACION
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.

6 DISEÑO – ELABORACION CASOS PRUEBA
1.4 Pasos a Seguir:

7 DISEÑO – MATRIZ DE REQUERIMIENTOS
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?

8 DISEÑO – MATRIZ DE REQUERIMIENTOS
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.

9 DISEÑO – MATRIZ DE REQUERIMIENTOS
Compuerta Exclusiva Compuerta Inclusiva Compuerta Paralela Se debe registrar un requerimiento de prueba derivado por las diferentes condiciones de enrutamiento que se puedan presentar. 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

10 DISEÑO – MATRIZ DE REQUERIMIENTOS
Compuerta Exclusiva Compuerta Inclusiva Compuerta Compleja 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.

11 DISEÑO – MATRIZ DE REQUERIMIENTOS
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

12 DISEÑO – MATRIZ DE REQUERIMIENTOS
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.

13 DISEÑO – MATRIZ DE REQUERIMIENTOS
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

14 DISEÑO – MATRIZ DE REQUERIMIENTOS
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.

15 DISEÑO – MATRIZ DE REQUERIMIENTOS
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)

16 DISEÑO – MATRIZ DE REQUERIMIENTOS
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.

17 DISEÑO – MATRIZ DE REQUERIMIENTOS
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

18 DISEÑO – MATRIZ DE REQUERIMIENTOS
Resultados Esperados a nivel de enrutamiento del proceso : Compuerta Exclusiva Compuerta Inclusiva Compuerta Paralela El resultado esperado consiste en describir la figura del proceso con la cual se debe continuar.

19 DISEÑO – MATRIZ DE REQUERIMIENTOS
Resultados Esperados a nivel de interfaz gráfica (Visibilidad, Obligatoriedad, Editabilidad, Comportamiento de Campos, Grupos, Validación de Condiciones):

20 DISEÑO – MATRIZ DE REQUERIMIENTOS
Resultados Esperados a nivel de datos:

21 DISEÑO – ELABORACION CASOS PRUEBA
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.

22 DISEÑO – ELABORACION CASOS PRUEBA
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.

23 DISEÑO – ELABORACION CASOS PRUEBA
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.

24 DISEÑO – ELABORACION CASOS PRUEBA
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.

25 DISEÑO – ELABORACION CASOS PRUEBA
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.