Haga clic para modificar el estilo de subtítulo del patrón 4/11/10 Noviembre 4, 2010 Inicio de 1er Ciclo de Pruebas: CRP 1 - MODULARES

Es aplicar un escenario o transacción en el sistema, que se relaciona con un módulo de Oracle, y que no depende o proviene de otro proceso generado en el sistema. Por ejemplo: Aunque sabemos que una orden de venta proviene de PIP, la prueba unitaria únicamente relaciona al módulo de Ordenes de venta y la creación de una orden de venta, Aunque sabemos que un pago en Cuentas por Pagar requiere la impresión de un cheque, la prueba unitaria únicamente relaciona la generación de la transacción en el módulo, Aunque una factura de cuentas por pagar debe provenir de una orden de compra, la prueba unitaria únicamente considera la generación de la factura directamente en el módulo. Qué son pruebas unitarias o modulares?

Comprobar que el sistema (módulos) funciona “bien”, que inicia y termina bien un proceso unitario, Probar al menos un escenario de cada uno de los procesos que se diagramaron en la etapa de Diseño de Solución (Total: 143 proceso), Validar que mi operación actual (sin interfaces, conexiones con otros módulos, reportes o formatos customizados) se cumple con la configuración del sistema de pruebas, Conocer, aprender y comprender la nueva funcionalidad que me ofrece el sistema. Objetivos de este ciclo CRP1

Los escenarios de pruebas fueron creados por el usuario, aunque complementados y/o revisados por el consultor, Los escenarios de pruebas se crearon a partir de los 143 diagramas de procesos unitarios que se definieron y revisaron en Diseño de Solución (usuario clave y consultor), Los escenarios de pruebas incluyen también mi operación diaria con sus estándares y excepciones, Se ha notificado la creación de un reporte en SEA, destinado a colocar los resultados de las pruebas Se cuenta con un ambiente extra (copia de TEST) para que el usuario practique y genere tantos escenarios como necesite para comprobar su operación y practicar en el nuevo sistema. Supuestos

Los resultados de las pruebas deberán subirse al reporte de SEA, con toda la información que los Scripts de pruebas solicitan, El estatus de la prueba puede ser: A probado: la prueba ha sido superada y el resultado es el esperado Rechazado: la prueba no ha sido superada. Si el sistema no respondió como se esperaba, se compone el error (técnico o configuración) y se lleva a cabo la prueba nuevamente, Si el sistema no cumple con la expectativa y se requiere un diseño nuevo, se escala el problema a Maria Antonieta y/o Francisco para buscar una solución al mismo Si surge un nuevo requerimiento por parte del usuario, se escala a Maria Antonieta y/o Francisco para darles una respuesta y/o solución al mismo, Resultados

PREGUNTAS Y PUNTOS VARIOS