Establecer el flujo del proceso de verificación de una versión antes de su despliegue en un entorno productivo. Se incluye también como objetivo la validación de los desarrollos que se hacen en un sprint cuando los proyectos se gestionan de forma ágil.

Alcance

Este proceso aplica a los productos de tipo aplicación que se gestionan en JIRA.

Roles

Los roles que intervienen en este proceso son

Flujo del proceso

Verificación y validación asociadas a una versión

Cuando una versión comienza su ejecución, es posible comenzar con la fase de testing temprano asociado a las fases de requisitos, análisis y diseño. Esta revisión de la documentación es llevada a cabo por la Oficina de Calidad y se modela en el Servicio de Testing Temprano (STT).

Cuando la versión ha sido desarrollada, normalmente se prepara para el despliegue en el entorno de Preproducción. Para ello es necesario hacer una verificación de que el software construido funciona correctamente antes de el despliegue en PRE. Esta verificación se modela en el Servicio de Verificación de entregas (SVE). Es condición necesaria que este servicio esté acabado antes de poder hacer la petición de lanzamiento para el despliegue en PRE (a menos de que se trate de una petivión de lanzamiento urgente, PLU).

Una vez que la versión ha finalizado su desarrollo, puede comenzar la validación de la misma en base al plan de pruebas. Esta validación puede ser realizada por el Responsable Funcional/Responsable de producto o bien por la Oficina de Calidad. En este último caso, la validación se modela en el Servicio de Validación Funcional (SVF), donde se determina si se ha construido el software deseado en base a a los requerimientos y siguiendo el plan de pruebas. En el caso de que la validación sea satisfactoria, la versión será candidata a desplegarse en un entorno productivo.

En el caso del Servicio de Testing Temprano, del Servicio de Validación funcional y la validación que pueden hacer Responsable Funcional/Responsable de producto, cualquier fallo se registra como una No conformidad.

Modelado de las pruebas en proyectos gestionadas con metodología en cascada

Los requisitos deben ser especificados por el proveedor a nivel de mejora. De cada mejora se originarán n casos de uso (auqnue un caso de uso sólo puede estar originado por una mejora).

Para cada caso de uso creado por el proveedor, la OCA

registrará uno o más tests que proporciona el proveedor. Un mismo test puede servir para probar diferentes casos de uso, pero siempre teniendo en cuenta que todos deben estar originados por la misma mejora.

Actualmente esos tests se documentan en el Enterprise Architect, pero en breve se crearán directamente en JIRA.

Cuando se cierra de manera satisfactoria la primera PL

HIJA de la versión en la que se incluye una mejora, sus casos de uso pasan a estado VIGENTE y se informa en ellos con el código de la versión, las versiones afectadas y correctoras de los mismos.

Para los tests asociados a los casos de uso, se informan también las verisones afectadas y correctoras y pasan a estado EN RESOLUCION.

Existen además dos validaciones que realiza la Oficina de Calidad y que pueden ser realizadas bien con la versión sin ser desplegada en entornos productivos o bien una vez que la versión esté implantada. Son:

• Servicio de validación de la accesibilidad (SVA):  Persigue lograr que las páginas web/aplicaciones móviles sean utilizadas por el máximo número de personas, independientemente de sus conocimientos o capacidades personales.
• Servicio de validación de la usabilidad (SVU):  Persigue medir los objetivos de usabilidad en términos de eficacia, eficiencia y satisfacción facilitando información sobre las funcionalidades susceptibles de mejora del producto.

En estos dos últimos casos, si la versión está ya desplegada en un entorno productivo, no procederá el registro de No conformidades y la Oficina de Calidad emitirá sólo un informe con posibles incidencias y recomendaciones de mejora.

Verificación y validación asociadas a un sprint

En le caso en que la gestión del producto se haga en base a sprints, en cada uno de ellos la Oficina de Calidad hace una verificación/validación de lo que se desarrolla en cada uno de esos sprints, modelada en el Servicio de Verificación de Sprints (SVS).

Aquellos posibles fallos detectados se registran como bugs, a partir de los cuales será necesario crear historias de usuario que se incluirán en sprints venideros. Una vez desarrolladas esas historias de usuario, la Oficina de Calidad validará si el bug se ha corregido o no.

Modelado de las pruebas en proyectos gestionadas con metodología ágil

Los requisitos deben ser especificados por el proveedor a nivel de historia de usuario.  Cada historia de usuario se relaciona con n tests. En los tests y en las historias de usuario se informan versiones afectadas y correctoras de la siguiente forma:

• Si la HU ha sido originada por una mejora se informarán en la HU las versiones afectadas y correctoras cuando se cierre de manera satisfactoria la primera PL HIJA de la versión en la que esté incluida dicha mejora.
• Si la HU ha sido originada por una incidencia se informarán en la HU las versiones cuando se cierre de manera satisfactoria la primera PL HIJA de la versión en la que esté incluida dicha incidencia.
• Si la HU ha sido originada por una NO CONFORMIDAD se informarán en la HU las versiones cuando se cierre de manera satisfactoria la primera PL HIJA de la versión en la que esté incluida dicha NC.
• Si la HU ha sido originada por uno o más bugs se informarán en la HU las versiones cuando se cierre de manera satisfactoria la primera PL HIJA  de la versión en la que esté incluida la mejora que ha originado la HU enlazada con el test que ha originado el bug. En estos casos los bugs siempre están enlazados a un test.

HU<--Bug <--Test<--HU<--Mejora→Versión

Tabla de estados y acciones

Para acceder al manual JIRA donde se detallan los estados, acciones y roles que pueden actuar en cada punto del flujo,

pulsa aquí.