Pégina des MINISTERIO DE SALUD - SSI cae PROCEDIMIENTO PARA LAS PRUEBAS DE ACEPTACION DE SISTEMAS igo: Pross-o=z Fecta: Agosto 2014 4. oBJeTIvo Definir as actividades y reistros para las pruebas de aceptacién de sistemas desarrollados 2. ALCANCE plicable @ todos los sistemas de informacién desarrollados de manera interna y externa en el Minsal Este procedimiento es aplicable a todos los funcionarios (planta, contrata, reemplazos y suplencia), personal a honorarios y terceres (proveedores, compra de servicios, etc), que presten servicios para las Subsecretarias de Salud Publica y Redes Asistenciales. 3. DESARROLLO DEL PROGEDIMIENTO 3.1 Responsabilidades. Encargado Unidad de Administracién y Operaciones: Debe velar por el cumplimiento del Proceso general de desarrollo de sistemas y los controles establecidos en el presente procedimiento. Jefe de Proyecto: Debe generar el plan de pruebas, coordinar, evaluar y registrar las pruebas de aceptacien. Referente de Negocio o usuario final: Debe definir a los funcionarios que participaran en las pruebas de aceptacion, realizar las pruebas de aceptacién en coordinacién con el Jefe de Proyecto, junto con firmar el informe de resultado de pruebas de aceptacion. 3.2. Proceso General del Desarrollo de temas El presente procedimiento da cuenta de las pruebas de aceptacién de la etapa Testing y Pruebas de aceptacién de Sistema del Procedimiento para el desarrollo de sistemas, como lo indican las figuras siguientes: Figura 1: Proceso general del desarrollo de sistemas. ommctn eaaremaerrncin macnn rannesenaraaie —y Fanndcn ions arrest Toda versin imoresa de este documenta se considera come Conia No ControladaPagina 2de 4 eo ‘Versi 02 MINISTERIO DE SALUD - SI PROCEDIMIENTO PARA LAS PRUEBAS DE ACEPTACION DE SISTEMAS Mad®:PROSSIC= Fecha: Agosto 2014 3.3 Consideraciones generales Las pruebas de aceptacién tienen como fin validar que el sistema cumple con los requisitos basicos de funcionamiento esperado y permitir que el referente de negocio determine su aceptacién. Las pruebas de aceptacién deben ser realizadas por el referente de negocio junto al Jefe del Proyecto y las Personas que se estimen pertinentes. En esta etapa el usuario final debe plantear todas las deficiencias 0 errores que encuentre antes de dar por aprobado el sistema definitivamente, El Jefe de Proyecto junto al referente del negocio deben disefiar un plan con las pruebas de aceptacion que seran utiizadas para la aceptacién del sistema, Cuyo ciclo debe considerar al menos los siguientes puntos: + Definir los casos de uso que validan la funcionalidad y no funcionalidad del sistema. + Preparar datos de las pruebas de aceptacién + Validar datos de los casos de prueba de aceptaciOn y pruebas de Sistema. + Definir el procedimiento de la prueba. ‘+ Ejecutar las pruebas de aceptacién. ‘+ Comparar los resultados de las pruebas con los resultados esperables para cada caso de uso, ‘+ Documentar las pruebas de aceptacién. ‘+ Sera responsabilidad del Jefe de Proyecto consensuar con el referente el negocio los criterios de aceptacién de cada sistema y dirigir las pruebas que se ejecuten para tales efectos, estas pruebas deben realizarse considerando: ‘Sera responsabilidad del Jefe de Proyecto consensuar con el referente el negocio los criterios de aceptacién de cada sistema y dirigir las pruebas que se ejecuten para tales efectos, estas pruebas deben realizarse considerando: + Todas y cada una de las versiones del software en desarrollo, + Debe habilitarse un ambiente especial para tales fines (ambiente de testing) + Cualquier error encontrado debe ser registrado e informado al equipo de desarrollo para su correccién + Cada vez que se libere una correccién al sistema, el equipo de desarrollo, a través del Jefe de Proyecto, informaré al equipo de pruebas para que éste valide si el problema fue satisfactoriamente subsanado, + Caso especial se tiene cuando el software que se est probando corresponde a una aplicacién de reemplazo ya que en este caso se debe realizar es un plan de migracién que contemple pasos a pproduccién por partes, sinoronizacién de datos, vuelta atrés en caso de fallos, etc. + La vuelta atras por temas de contingencias (falla del nuevo aplicativo) debera ser ejecutada por la Unidad de Administracion y Operaciones en conjunto con el equipo de desarrollo del proyecto, ‘uienes se aseguraran de dejar plenamente operativa la aplicacién en su versién inmediatamente anterior a los cambios desarrollados. Una vez concluidas las pruebas de aceptacién el Jefe de Proyecto debe elaborar un informe con los resultados de las pruebas de aceptacién firmada por el referente de negocio o usuario final 34 Preparacién de las pruebas de aceptacién El Jefe de Proyecto analiza los criterios de aceptacién establecidos por el usuario y recogidos en las verficaciones del plan de pruebas, por si fuera necesario incorporar algun caso de prueba adicional. ‘Se deberé comunicar el plan de pruebas de aceptacién una vez actualizado, a los usuarios implicados en las pruebas de aceptacién, Productos * Plan de pruebas (corregido o ajustado). Toda varsin imoresa de este documento se considera como Conia No ConroadaPigina 3dea MINISTERIO DE SALUD - SSI Version: 02 PROCEDIMIENTO PARA LAS PRUEBAS DE ACEPTACION DE SISTEMAS “Bao: Pross-z Foci: Agosto 2014 3.5 Planificacién de Pruebas A continuacién se detallan los contenidos de la planificacién referida al plan de pruebas de aceptacién, = Actividad. + Responsable, Fecha inicio de la actividad ‘= Fecha de término de la actividad + Duracién. 3.6 Realizacién de las pruebas de aceptacin El Jefe de Proyecto coordina y dirige las pruebas de aceptacién final del sistema para asegurar que todos los componentes responden a los criterios de aceptacién especificados, Se registra la realizacion de las pruebas, incluyendo un informe que recoja la desviacién de los requisitos establecidos y los problemas que quedan sin resolver. 3,7 Criterio de aceptacion Eljefe de proyecto elaborara un ranking para cada Caso de Uso (CU) con las siguientes prioridades: ALTA, MEDIA 0 BAJA y en base a ellas se le asignard un mayor nimero de pruebas para los CU con un mayor nivel de prioridad, Las pruebas serdn validadas por el referente de! negocio antes de ser ejecutadas, y posteriormente los resultados obtenidos seran entregados en una tabla de evaluaciOn de las pruebas, la cual debe poseer al menos un 85% de satisfaccién para que el Software sea aprobado. Para el 15% restante se definira un plan de correccién el que una vez terminado obligara a ejecutar nuevamente el plan de pruebas de aceptacion hasta logra una conformidad del 100% respecto del documento de especiicacion de requerimientos, 3.8 Evaluacién de los resultados de las pruebas de aceptacion El Jefe de Proyecto debe evaluar los resultados de las pruebas, analizando las incidencias recibidas y ‘comprobando que se han llevado a cabo todos los casos de pruebas establecidos en el plan de pruebas. La ‘evaluacién consiste en: CComparar los resultados obtenidos con los esperados. Identificar el origen de cada problema para poder remitirlo a quién proceda y determinar. Determinar las acciones o medidas correctoras que son precisas llevar a cabo para resolverlo de forma satisfactoria ¥ Indicar qué pruebas se deben volver a realizar, o si sera necesario contemplar nuevos casos de prueba sas Una vez realizadas las medidas correctoras necesarias, y comprobado que su comportamiento es adecuado, El Jefe de Proyecto documenta en el Informe de resultados de pruebas de aceptacién el resultado global de la evaluacion de las pruebas, el que debe ser firmado por el referente de negocio 0 usuario final. |. DOCUMENTOS APLICABLES 0 RELACIONADOS’ Procedimiento control de acceso al cédigo fuente. Procedimiento para el desarrollo de sistemas, NCh-IS027001:2009: Tecnologia de la informacién - Técnicas de seguridad - Sistemas de gestién de la seguridad de la informacion - Requisitos, punto A. 10.3.2. * Las paltcas © procedmientos referencias pueden ser consutads en ipilweb.minsa ci Ja infor ‘oda versin imoresa de este documento se considera como Cola No Contoladaie Versi 02 ne ‘MINSTERIO DE SALUD S81 | PROCEDIMIENTO PARA LAS PRUEBAS DE ACEPTACION DE SISTEMAS | “#30 FROSSIO# | Fecha: Roost | 2014 5. CONTROL DE REGISTROS | ene Almacenamients _cién 3 Informe resultado Permisos de renee de pruebas Carpeta de proyecto acceso a Por proyecto NIA te | de Carpeta | | aveptacién. L : | 10 Zamorano R. Inf Eduardo igo Castro A, Unidad de Cor Eneargado Uni Preside] Comite de Seguridad ‘Administracion y Operaciones Edgardo Pind K. \ reared nia do Conte de resupue “Gestion y. oda version imoresa de este documento so considera como Conia Ne Controada