Versión: v01r01 Estado: ACTIVO Entrada en vigor desde: Contacto Dpto: Oficina de Calidad |
Histórico de cambios
Los cambios en las publicaciones vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución.
| ||||||||||||||||||
1. Introducción
Este documento está dirigido a los proveedores responsables del desarrollo y mantenimiento del producto que siguen metodologías en cascada. Su propósito es introducir el flujo de trabajo en Jira, diseñado para el registro y gestión de la ejecución de pruebas validadas en el entorno del desarrollo , de forma estruturada y trazable, donde el proveedor podrá registrar los resultados de las pruebas validadas incluyendo evidencias del resultado satisfactorio o evidencias de defectos identificados que requieren correcciones.
El modelo descrito permite:
Centralizar la información de testing en Jira (planes, ejecuciones, resultados y evidencias) permitiendo un seguimiento unificado y auditable.
Asegurar la trazabilidad entre requisitos, casos de uso, pruebas y resultados.
- Estandarización de procesos de validación, resuciendo errores y duplicidades.
Mejorar la coordinación y comunicación entre los distintos actores involucrados en los proyectos, proveedor, área de proyectos y funcionales, Oficina de Calidad (OCa) y otros departamentos de DGSIC.
Facilitar la revisión y validación en fases posteriores, garantizando cumplimiento de los requisitos funcionales, permitiendo determinar si se ha construido el software deseado, y por lo tanto que la entrega es candidata a desplegarse en un entorno productivo.
Reducir tiempos y errores en la fase de validación gracias a la reutilización y control de los artefactos de prueba.
2. Creación de un Test Execution
En proyectos que siguen metodología en cascada, una vez documentado en Jira la información funcional (mejoras,requisitos, casos de uso y casos de pruebas) siguiendo las pautas normativas, el proveedor determinará qué pruebas serán necesarias para validar las mejoras en vuelo cuyo desarrollo está en su fase final. Se puede plantear la posibilidad de generar Test Execution por Mejora que se desea validar y/o por versión candidata para el próximo despliegue en entorno preproductivo, incluyendo todas las pruebas relacionadas con el alcance completo de la misma. De forma que deberá dar de alta la entidad Test Execution. Existen varias formas para crear dicha entidad que serían las siguientes:
- A partir de un Test Plan elaborado previamente por el proveedor con las pruebas a validar.
- Sin Test Plan, es decir, el Proveedor crea directamente el Test Execution añadiendo los Test a validar.
2.1 Creación del Test Execution a partir de un Test Plan
Antes de crear el Test Execution, el proveedor deberá crear en Jira la entidad "Test Plan" de la versión que corresponda (3 dígitos) siguiendo los siguientes pasos:
Seleccionar la opción "Crear" de Jira para dar de alta el Test Plan.
Se abre un formulario con los siguientes campos a rellenar:
Proyecto*
Tipo de Registro*
Título* (se recomienda seguir la siguiente nomenclatura: "[Clave del Proyecto en JIRA] - X.Y.Z - Plan de pruebas funcionales")
Asignar
Descripción
Subsistemas
ID versión relacionada*
Etiquetas
- Fecha de inicio (se cumplimenta de forma automática al avanzar de estado a "En resolución")
- Fecha fin (se cumplimenta de forma automática al resolver el test plan)
Test asociados con un plan de testing (en este campo se podrá seleccionar un Test Set con pruebas de una versión concreta)
A partir del Test Plan creado, el proveedor podrá crear en Jira el Test Execution correspondiente mediante la opción "Crear ejecución de Tests → Todos los Tests o Con estado", permitiendo seleccionar los casos de prueba a ejecutar.
Los campos a rellenar serán los siguientes:
Proyecto*
Tipo de Registro*
Título* (se recomienda seguir la siguiente nomenclatura: (Clave del Proyecto en JIRA) - W.X.Y - Ejecución plan de pruebas funcionales)
Asignar
Descripción
ID versión relacionada
Entrega
Entorno (PRO, PRE, Entorno proveedor, Implantación, Desarrollo, Prepil, Otros)
Etiquetas
Fecha de inicio (se cumplimenta de forma automática al avanzar de estado a "En resolución")
Plan de Testing (se cumplimenta de forma automática con el código Jira del Test Plan)
Tests (este campo permite seleccionar Test ya creados con anterioridad para ser incluidos en el Test Execution).
El proveedor tendrá permisos de edición en tiques de tipo "Test Plan" y "Test Execution" creados por él para poder actualizar los campos mencionados anteriormente.
2.2 Creación del Test Execution sin Test Plan asociado
La creación de un Test Execution, sin Test Plan asociado, está disponible usando directamente la opción "Crear" de Jira. Esta opción abre un formulario en el que si seleccionamos "Tipo de Registro=Test Execution" se precargan los mismos campos mencionados en el apartado anterior cuando creamos el Test Execution a partir del Test Plan.
En este caso, el campo "Plan de Testing" estará vacío y con los valores de selección "DESARROLLO" o "Entorno proveedor" en el campo "Entorno" no será necesario informar "Entrega" e "ID Versión relacionada". Una vez creado el Test Execution, el proveedor podrá añadir Test mediante la opción "Añadir "→ "Tests" o "Tests de Grupos de Tests", en caso de que se desee seleccionar un Test Set ya creado con anterioridad" (ver Figura 4).
Este método resulta útil en entregas parciales, sin necesidad de un plan de pruebas completo.
Este Test Execution también podrá ser editado por el proveedor una vez creado.
2.3 Creación de Test Set para organizar las pruebas
El Test Set permite organizar las pruebas por versión o por ámbito funcional, agrupando los casos de prueba de una versión específica (X.Y.Z)
Para llevar a cabo esta organización, podrá crear un tique de tipo "Test Set" desde Jira para albergar las pruebas correspondientes a una versión concreta del proyecto. Para ello deberá seguir los siguientes pasos:
Seleccionar la opción "Crear" de Jira para dar de alta el Test Set.
Se abre un formulario con los siguientes campos a rellenar en Pestaña general:
Proyecto*
Tipo de Registro*
- Título* (se recomienda seguir la siguiente nomenclatura: (Clave del Proyecto en JIRA) - Conjunto de pruebas de la versión X.Y.Z)
- Asignar
- Descripción
- Etiquetas
- Subsistemas
- Version(es) afectadas: versión de 3 dígitos dada de alta previamente en Jira.
- A rellenar en Pestaña "Tests":
- Pruebas (códigos Jira del conjunto de Tests de la versión "X.Y.Z")
El proveedor por tanto puede crear un Test Plan que englobe pruebas de una versión seleccionando el Test Set creado previamente. Para ello se usará la opción "Tests de Grupos de tests" desde el Test Plan (ver Figura 5). En el desplegable que aparece (ver figura 6) se buscará el Test Set a partir del código Jira. Una vez seleccionado, el Test plan se actualizará con las pruebas del Test Set.
Hay que tener en cuenta que un Test Plan puede albergar pruebas de una versión específica, pruebas de regresión, o un subconjunto de pruebas de una versión concreta, etc, es decir, el Test plan funciona como una entidad que puede contener todas aquellas pruebas que el proveedor necesita validar en su propio entorno de desarrollo y permite ejecución repetible acumulando varios ciclos de pruebas si se precisan.
El proveedor tendrá permisos de edición en tiques de tipo "Test Set" creados por él para poder actualizar los campos mencionados anteriormente.
3. Registro de resultados
Cuando el proveedor ya dispone del Test Execution con las pruebas a validar, hay que tener en cuenta los siguientes puntos:
Tal y como hemos comentado en el apartado 1.2, cuando el "Entorno" seleccionado es "DESARROLLO" o "Entorno proveedor" la información de los campos "Entrega" e "ID Versión relacionada" es opcional.
Por otro lado, en estos entornos, se podrán registrar los resultados de las pruebas aunque los Test estén en estado "ABIERTO" y sin versión asignada. Es importante recordar que la OCA, en una fase posterior, una vez cerrado el alcance de una versión y desplegada la misma en entornos preproductivos de DGSIC ,llevará a cabo la ejecución de las pruebas del producto a través del Servicio de Validación Funcional (SVF), es decir, una vez que se ha implantado el producto en PRE.
En los entornos de trabajo "DESARROLLO" o "Entorno proveedor" los defectos identificados en la aplicación, no generarán un registro tipo "No conformidad" o "Bug" sino que deberá incluir en el resultado del Test un comentario del error producido y adjuntar una evidencia. Incluimos a continuación un ejemplo:
- También se deben incluir en las evidencias del resultado satisfactorio en las ejecuciones de cada test