Objetivo

El presente documento tiene como objeto estandarizar los procedimientos de pruebas de versiones nuevas del Sistema de gestión integral de expedientes SUDOCU implementado en la Universidad Nacional de Luján. El fin último de la observación de lo aquí mencionado será facilitar un esquema de trabajo estandarizado, para que los sectores usuarios del sistema puedan establecer, en un tiempo y cantidad de trabajo mínimos, que una nueva versión de SUDOCU cumple con el funcionamiento aceptable para ser instalado en producción.

Alcance

En el presente procedimiento tendrá intervención el personal Técnico a cargo de la administración del sistema SUDOCU y el personal Nodocente afectado a la utilización del mismo, llamados también Usuarias/os.
 

Responsabilidades

Existen dos responsabilidades primarias en relación al presente procedimiento. La primera es relativa a la actualización de este mismo documento. La otra es la que tiene que ver con el observar el cumplimiento y ejecución del procedimiento definido aquí.
 

Responsable del documento

El responsable de la actualización del presente documento es el Equipo Técnico del sistema SUDOCU, dependiente de la DGS, de acuerdo al esquema establecido y en concordancia con las políticas de seguridad informática de la Universidad.
 

Responsable de cumplimiento y ejecución del procedimiento

El responsable del cumplimiento del presente plan es la parte Usuaria del sistema SUDOCU de la UNLu.

Régimen de actualización

El presente documento será actualizado en el caso de detectarse la necesidad de efectuar modificaciones en relación a la realidad de la estructura funcional y del ambiente informático. Los avisos sobre posibles cambios pueden ser solicitados tanto por la parte Técnica como por la parte Usuaria y debidamente notificados el resto de los miembros del proyecto.

Ante cada actualización, será obligatorio incluir una breve reseña en la sección Historial de Cambios a fin de facilitar su revisión. Se asentará el contenido modificado (agregado, eliminado, cambiado) y el autor.
 

Fundamentos de la Prueba de Versiones

En el contexto de este documento, se define como Prueba de versión a la actividad que la parte Usuaria realiza sobre una instalación alternativa a Producción, a los fines de detectar potenciales problemas que hagan inviable su actualización. Entre los potenciales problemas, destaca errores introducidos involuntariamente por el SIU. Si bien es algo poco frecuente en otros proyectos del SIU, es un escenario posible y la experiencia muestra que tomarse el tiempo de realizar la prueba redunda en un beneficio tanto para la UNLu como para el SIU, quienes reciben avisos tempranos de estos errores y pueden disponer de tiempo y recursos para su solución.

En algunos casos, los problemas detectados pueden deberse a un error de programación. En otros, a problemas de configuración. En ocasiones, puede existir un problema con el conjunto de datos particulares de UNLu y no con otras universidades. En todos los casos, una prueba de funcionalidad lo más exhaustiva posible será de utilidad para que estos problemas no aparezcan en Producción.

En ciertas circunstancias, el SIU puede hacer entrega de nueva funcionalidad. La prueba puede ayudar también para entender cómo funcionan esas nuevas características en un entorno que no sea Producción, lo que ofrece posibilidades de experimentar sin consecuencias negativas.

Roles del proceso de pruebas

Existen varios roles o grupos de personas involucrados en el proceso de pruebas. A continuación se los lista, para poder utilizarlos en adelante.

Técnicos: Sector dependiente de la Dirección General de Sistemas, encargado de poner a disposición la versión a ser probada y dar aviso a los Usuarios cuando la misma esté disponible para la Prueba. Además, recibe los reportes de errores, da aviso al SIU en caso de ser necesario e instalará la versión en Producción luego de que los usuarios finalicen la Prueba de forma satisfactoria.

Usuarios: Trabajadores de la UNLu que hacen uso del sistema desde lo funcional y que sean elegidos como representantes de su oficina o sector para probar la funcionalidad.

Coordinador de la prueba: Persona de la parte Usuaria encargada de centralizar la comunicación entre estos y los Técnicos. Su responsabilidad se limita a dar aviso a Usuarios de que se encuentra disponible la prueba y a centralizar los resultados. No es responsable de que los sectores lleven a cabo la prueba, ya que eso es competencia de cada usuario.

Estos roles serán consensuados por todas las partes y no son estáticos, podrían modificarse de una prueba a otra según disponibilidad de la gente para realizar las pruebas.

Ademas de lo aquí descrito, existe un rol extra que no será consensuado y es el responsable de mayor rango jerárquico del sector usuario del sistema, que interviene en un paso sobre el final del proceso de prueba.
 

Procedimiento de Prueba

Los pasos a llevarse a cabo para dar por realizada la prueba son:
 

• Liberación de nueva versión (Equipo Técnico EEI - SIU)
• Descarga e instalación en instancia de Pruebas (Equipo Técnico DGS - UNLu)
• Aviso a Coordinador de Prueba a disposición (Equipo Técnico DGS - UNLu)
• Aviso a Sectores usuarios de nueva versión a ser probada (Coordinador de Prueba - UNLu)
• Realización de las Pruebas (Usuarios - UNLu)
• En caso de errores, reporte tal como se indica en el procedimiento respectivo
• Notificación de Pruebas Satisfactorias a Coordinador (Usuarios - UNLu)
• Notificación de Pruebas Satisfactorias y fin de las pruebas a superior jerárquico y DGS (Coordinador de Prueba - UNLu)
• Nota Formal a DGS indicando final satisfactorio de las pruebas (Superior Jerárquico del Sector Usuario del Sistema)
• Coordinación e instalación de nueva versión en Producción (Equipo Técnico DGS - UNLu)

Tipos de Pruebas

Se pueden definir algunos tipos de pruebas, en relación a la cantidad de trabajo que implican para la parte Usuaria el poder darla por finalizada. Estos tipos se listan a continuación.
 

Prueba Completa o Exhaustiva

Este tipo de prueba conlleva probar todas y cada una de las funciones y opciones del sistema por cada perfil. Es la prueba más costosa en tiempo y trabajo, pero, a su vez, la que minimiza la posibilidad de problemas al implementarse en Producción.

INFO

Este es el tipo de prueba a realizar, a menos que en alguna ocasión precisa se explicite otra cosa.

Este tipo de prueba puede implicar, además, la coordinación entre varios sectores, para probar funcionalidad compartida. Ejemplo: Pase de documentación.

Prueba parcial

Implica que cada sector probará la funcionalidad más utilizada por ellos con las opciones más comunes. Minimiza la posibilidad encontrar problemas en las tareas cotidianas, pero aumenta el riesgo de que algo que se utiliza con menor frecuencia presente inconvenientes para su gestión.

Estas pruebas suelen tener lugar en contextos donde la parte Usuaria se encuentre con carga de trabajo diario más alta de lo normal debido a situaciones atípicas y exista una necesidad de implementar la versión lo antes posible.

Un ejemplo de Prueba Parcial podría ser este documento de la documentación oficial.

Prueba mínima

Esta pràctica plantea reducir al mínimo la cantidad de trabajo y tiempo asociado a la Prueba. Se considera poco recomendable en la gran mayoría de contextos, aunque puede resultar útil ante versiones que contengan arreglos de problemas urgentes y puntuales. Suelen ser versiones con pocos cambios incluidos (hasta podría ser un solo cambio). En este caso, podría considerarse una Prueba mínima.
 

Documentación de las Pruebas

Se entiende por documentación de las Pruebas a cualquier grupo de documentos (digitales o físicos) que respalden la realización de las tareas llevadas adelante durante el proceso. Estos documentos relevan las acciones hechas sobre la nueva versión y tienen varios objetivos:
 

• Dejar asentado qué pruebas se hicieron para una versión determinada
• Relevar qué fallos introdujo una versión determinada
• Generar una base de pruebas para siguientes versiones (esto implica que se generan pruebas repetibles y comparables)

En su forma más resumida, el contenido debe entenderse como una identificación de la tarea realizada, el estado de la misma (éxito o fallo), fecha de realización y Usuario que la ejecutó. En forma ampliada, pueden incluirse pasos realizados, datos introducidos en los formularios, salidas esperadas y salidas obtenidas.

La cantidad de documentos puede ser variable. En principio, parece razonable que cada sector que prueba genere un único documento. Sin embargo, si alguno de los sectores tiene módulos con mucha funcionalidad, bien podrían decidir, a su vez, generar un documento por cada módulo. Si el formato es homogéneo, la decisión sobre si hacer uno o varios documentos que respalden las actividades de pruebas es potestad de cada sector.

Ejemplo de Documentación

Se propone un ejemplo de planilla para documentar las Pruebas. La misma se deja disponible en formato de planilla de cálculos. Si bien la misma no agota todas las posibilidades, se considera como una base para los sectores, que pueden modificar o extender según las necesidades lo requieran. A continuación se explica la lógica con la cual se podrían documentar las Pruebas haciendo uso de la planilla.

La idea inicial es que de esta planilla se haga una nueva copia cada vez que sale una versión nueva para probar. De esta forma, la planilla hace de modelo o plantilla para las pruebas.

La parte superior es el encabezado de la planilla. Es una forma de resumir qué versión se está probando. Para ello, se identifica la misma con el número de versión (estará disponible en el sistema y en el aviso de los Técnicos de qué versión se trata). Los siguientes 2 campos son específicos del sector Usuario y refieren al sector que prueba y en qué fecha inicia dicho proceso. En el caso que la planilla refiera a un único módulo, también se puede consignar en el campo referido a ello. Si no, poner No Corresponde.

Luego se encuentra la parte de renglones, que nos refiere a cada paso de la Prueba. La idea es que cada renglón o paso identifique una pantalla que se está probando. A continuación se explica el significado de cada una de las columnas.

La columna Id Paso se plantea como un número secuencial que identifica cada uno de los pasos. Esto puede ser útil para referirse a ellos en alguna nota u observación.

En la columna Perfil se debe poner el perfil de Usuario.

En Caso de Prueba se espera un nombre que agrupe los pasos y que refiera a una operación completa, que puede constar de varios pasos. Por ejemplo, un Caso de Prueba puede ser "Circuito en el módulo de gestión", el cual consta de varias etapas o pasos.

Para la columna Paso o Etapa (Nombre), es una referencia del paso en cuestión, por ejemplo, para el Caso de Prueba antedicho, un paso válido podría ser "Autorizar Documento".

En el caso de Datos cargados, es una columna optativa, solo para casos donde existan formularios en el paso en cuestión. Lo que se espera en este campo es un listado de datos cargados en el formulario.

Para Resultado de la prueba, se espera un indicador de "Funciona", "Falló" o "Funciona con error".

La columna Observaciones servirá para dejar registro de cualquier cuestión relevante. Por ejemplo, en el caso de error o fallo, describir cuál fue el fallo obtenido (pantalla de error, no hay pantalla pero el sistema no muestra que la acción se ejecutó, etc.). En caso que el error muestre un código, también puede ser registrado acá.

Por último, las columnas Usuario/a y Fecha son referencias al nombre de Usuario que probó y en qué día y hora hizo el paso. Esto es importante en el caso de errores, ya que los registros de depuración del sistema muestran la fecha y hora, entonces es muy útil para hacer los rastreos pertinentes.

Tiempo de Prueba de una versión

No se pone un tiempo de prueba límite de antemano, principalmente porque cada versión puede diferir en la cantidad de características y arreglos que introduce. Ademas será necesario tener en cuenta la carga de trabajo de cada sector involucrado en la prueba de versión, lo cual es imposible de prever. La prueba se dará por finalizada en uno de los siguientes casos:
 

• Todos los sectores de Usuarios que deben probar llevaron a cabo la tarea y esta resultó satisfactoria.
• La parte Usuaria decidió asumir el riesgo de que una parte no sea probada (total o parcialmente).

En ningún caso la parte Técnica dará por finalizada la prueba de versión de forma unilateral.
 

Finalización de la prueba y paso a producción

En el Procedimiento indicado arriba, el final de la prueba de una versión implica una serie de condiciones:
 

• Cada sector que prueba finaliza correctamente su prueba y notifica al coordinador
• El coordinador de las pruebas notifica del resultado exitoso de las pruebas al superior jerárquico y al equipo técnico.
• El superior jerárquico entrega nota formal habilitando el pasaje a producción.
• El equipo técnico y el superior jerárquico coordinan fecha para el pasaje a producción (Esto es importante porque actualizar versiones de los sistemas implica que el mismo no se encuentre disponible durante una cantidad de tiempo variable)

En la nota formal que notifica la finalización satisfactoria de la prueba y habilita el pasaje a producción se debe especificar:
 

• Versión que se probó
• Conclusión de la etapa de prueba y de qué tipo de prueba se trató (completa, parcial, o algún detalle que deje constancia del tipo de verificación al que fue sometido el sistema);
• Resultados obtenidos satisfactorios, o bien que se acepta operar con las condiciones que se hayan encontrado (por ejemplo, en caso que una funcionalidad no les permita registrar la información de la manera exacta que requiere la UNLu, pero aún así pueda operarse)
• Sectores involucrados en el proceso de prueba (sectores o personas en particular)
• Solicitud de la actualización del sistema en Producción
• Cualquier otra condición o detalle a tener en cuenta al momento de actualizar
• De forma optativa, se podrá adjuntar detalles de las pruebas realizadas o la documentación generada, o hacer referencia a los Issues relacionados con el proceso.

Historial de Cambios

Septiembre 2022

Migración docu a Gestor de contenidos UNLu (Betina Marazzo)
 

Septiembre 2021

Versión inicial del Procedimiento (Tomas Delvechio)
Revisión general del texto, sin agregado de contenido técnico (Silvina Echecopar)