Contenido

1.1 Creación de la Mejora

Para la creación de una mejora, primero se selecciona la opción "Crear" en la cabecera de JIRA y esto abrirá un formulario de registro donde se tendrá que rellenar la siguiente información (los campos mandatorios quedan marcados con un "*"):

• Proyecto*: seleccionado automáticamente al proyecto actual pero puede modificarse, por ejemplo, a "Gestor de Informes")
• Tipo de Registro*: hay que seleccionar el tipo "Mejora"
• Título* 
• Descripción*
• Requisitos: esta información deberá estar correctamente cumplimentada de cara al desarrollo de la mejora solicitada y por tanto,  obligatorio en la transición de una Mejora de "Backlog" a "En Versión". Ver apartado 1.3 para más información.

1.2 Flujo de trabajo de la Mejora

Los estados por los que transición una mejora son: "WISHLIST", "BACKLOG", "EN VERSIÓN" y "CLOSED".

Cuando se crea inicialmente una mejora, ésta se crea en estado "WISHLIST" (lista de deseos). Es decisión de los actores JP/Funcional priorizar aquellas mejoras que se deseen incluir en una versión futura del proyecto, por tanto, si desean incluir una mejora, el JP debe aprobarla con la opción "Aprobar mejora" especificando la urgencia de la misma (Muy alta, Alta o Normal). Una vez aprobada la mejora, ésta pasará al estado "BACKLOG" a la espera de decidir si se incluirá o no en alguna versión concreta.

Si los actores JP/Funcional deciden finalmente incluir una mejora en una versión X.Y.Z, el JP podrá usar la opción "Asignar versión" para asignar la mejora a la versión que se seleccione en el campo "Versión relacionada", pasando la mejora al estado "EN VERSIÓN". Con esta acción se establece el tipo de relación "Está contenida en" entre la mejora y la versión. Es importante recordar que los requisitos se podrán informar desde el primer momento en que se registra la mejora. Si no se informan, será necesario editar la Mejora e incluir la  información sobre los requisitos que ha de cumplir el sistema para satisfacer los objetivos de la mejora antes de incluir la Mejora en una Versión.

Puede ocurrir que una mejora en estado "EN VERSIÓN" no se aborde finalmente por algún motivo que impide su implantación (por ejemplo falta de tiempo, cambio de alcance, etc.), así pues, el JP podrá usar la opción "Desasignar de versión" de forma que se elimina la relación establecida entre Versión-Mejora y la Mejora pasa al estado "BACKLOG" hasta que se decida de nuevo en qué versión incluirla.

Aclarar que los campos "Versión afectada" y "Versión correctora" de una Mejora se actualizarán automáticamente cuando se resuelva la primera PL hija. Se asignará la versión con la que está relacionada la mejora.

Por último, la Mejora pasará automáticamente al estado "CERRADA" cuando finaliza la PL padre.

Figura1. Formulario de registro de una mejora

1.3 Requisitos de una mejora

Los requisitos funcionales de una mejora se anotarán dentro del campo "Requisitos" y se escribirán en una tabla de forma ordenada con una nomenclatura específica RFXXX - Título. De la misma forma, los requisitos de integración de la Mejora que requieran pruebas funcionales de interoperabilidad, se podrán también incluir en la misma tabla, pero siguiendo esta otra nomenclatura: RINTXXX - Nombre. Por tanto, el formato de la tabla resultante tendría el siguiente aspecto:  

Cualquier otro tipo de requisito que pertenezca a la mejora, deberá enlazarse al tique de mejora. 

• Requisito de integración, url confluence espacio OTI donde están recogidos.
• Requisito No funcional, url confluence artículo arquitectura dentro del propio proyecto donde están recogidos) 
• Requisito de Información, url confluence artículo arquitectura dentro del propio proyecto donde están recogidos  (por ejemplo los datos del usuario pueden leerse de un certificado digital, en ese caso deberá indicarse en la descripción del requisito de información explicando donde estará almacenada la información asociada a dicho requisito de información).

2.1 Creación de Caso de Uso

De nuevo, en la cabecera de JIRA se selecciona la opción "Crear" para abrir un formulario de registro. Los campos del formulario de creación del CU son los siguientes:

• Proyecto*: Esta información se completa de forma automática.
• Tipo de Registro*: Hay que seleccionar el tipo "Caso de Uso".
• Título*: La nomenclatura que debe seguir este campo es la siguiente: CUYYY-XXX - Nombre (YYY coincidirá con el número asociado al subsistema al que pertenece el caso de uso (SUBYYY - Nombre), XXX será un número de tres dígitos que no podrá repetirse). En el caso de no agrupar los casos de uso por subsistemas se usará la notación habitual con sólo un nivel (CUXXX). 
• Entidad origen CU: Esta información es obligatoria, selección única y se completa de forma automática al realizar el registro desde la propia Mejora generando una relación del tipo "Está originada por" entre el Caso de uso y la Mejora. Aclarar que una mejora podrá estar relacionada con N casos de uso pero un caso de uso sólo podrá estar relacionado con una única mejora).
• Descripción: Ver Anexo I.
• Requisitos:  Aquí se hará referencia a los requisitos funcionales o de integración funcional de la mejora que se vayan a trabajar en el CU específico junto con los escenarios que cubrirán los distintos flujos del sistema. La forma de representar está información se hará en el formato de la tabla que mostramos a continuación (ver también captura inferior de la parte derecha de esta sección):

• Se deberán tener en cuenta las siguientes cuestiones: 

• • El número del escenario no se puede repetir.
  • Todos los escenarios deben estar relacionados con al menos un requisito.
  • Un Caso de Uso puede dar lugar de "1 a n" Casos de Prueba.
• Actores:  Seleccionar actor del desplegable. Si no está disponible, solicitar alta para el proyecto en Jira. Ver apartado 2.3.
• Subsistemas:  Seleccionar subsistema del desplegable. Si no está disponible, solicitar alta para el proyecto en Jira. Ver apartado 2.4.
• Componentes: Seleccionar componente del desplegable. Obligatorio para proyectos que siguen el modelo de gestión aplicación-componentes. (Figura 2.1.b)

Adicionalmente a cada caso de uso se enlazará en Jira el prototipo correspondiente, para asegurar que se dispone de toda la información necesaria para la correcta construcción de la necesidad, según aplique.

2.2 Flujo de trabajo de Caso de Uso

Los estados de un Caso de Uso son: "OPENED", "VIGENTE" y "CLOSED).

Cuando se crea el Caso de uso, su estado inicial será "OPENED" y así se ha de mantener por parte del proveedor. Una vez que la primera PLH (PL Versión Hija) llegue a estado "CERRADA" con resolución "RESUELTA", el Caso de uso pasará al estado "VIGENTE" y se actualizarán los campos "Versión Afectada" y "Versión Correctora" de forma automática.

En caso de que la funcionalidad descrita en el Caso de uso quede obsoleta, el Proveedor podrá cerrarlo pasando al estado "CERRADA" con resolución "Deprecada".

En caso de que el Caso de Uso esté relacionado con otros Casos de Uso, se usará el tipo de relación "relates to".

Figura 2.1.b. Formulario de registros de un Caso de Uso (Aplicación con componentes)Figura 2.1.a. Formulario de registros de un Caso de Uso (Aplicación sin componentes)

Figura 2.2 Definición escenarios de un Caso de Uso

2.3 Actores

Los actores representan un rol dentro de la aplicación o producto y se definen para especificar la relación respecto a funcionalidades concretas. En este contexto, los actores se deberán asignar dentro de los casos de uso en los que intervienen pudiéndose asignar más de uno al mismo tiempo, además, aunque el campo "Actores" es opcional no pueden existir casos de uso sin actores según normativa. 

Teniendo en cuenta que, dentro del proyecto asignado, existe un listado con actores ya creados, cuando se quiera crear o editar un tique del tipo "Caso de uso" existirá un selector con todo ese listado de actores. Para seleccionar un actor hay que presionar "Clic izquierdo" sobre el nombre de este, en caso de querer seleccionar multiples actores, se deberá mantener la tecla "Ctrl" y clicar sobre todos los actores que se quieran añadir. Finalmente, al presionar el botón "Guardar", los actores estarán relacionados al caso de uso en cuestión y, en otra pantalla, se podrá consultar esta relación junto con todos los CU que contengan esos actores.

2.3.1 Listado de actores

Para poder visualizar todo el listado de actores se abrirá una nueva pantalla accesible desde una opción en el menu lateral izquierdo llamada "Actores".

En este listado se mostrará la siguiente información: 

• Actor: Nombre del Actor
• Estado: Estado del Actor que podrá contener los valores Activo o Archivado
• Registros: Número de registros que coinciden con los actores e incluye un enlace hacia un filtro de Jira donde se muestran todos los tiques que incluyen el actor correspondiente

 2.3.2 Creación de actores

Los actores de una aplicación/componente se tendrán que dar de alta en Jira a través de un tique del tipo "Tarea general" en el proyecto "Estela". Se debe incluir en la descripción la siguiente información:

• Aplicación: nombre y código de la aplicación en Jira
• Actor: Nombre del Actor teniendo en cuenta la siguiente nomenclatura:
  • "ACTXXX - Nombre": los diferentes tipos de usuarios de la aplicación.
  • "SISXXX - Nombre": todos aquellos actores externos que interactúan con la aplicación. 

Figura 3. Formulario de registros: Añadir actores

Figura 4. Listado de actores

2.4 Subsistemas

Los subsistemas especifican agrupaciones funcionales del producto. Para cada proyecto se establecerán los subsistemas que sean necesarios y se informarán dentro de los Casos de Uso y Casos de Prueba (test).

2.4.1 Listado de subsistemas

Al igual que los actores, los subsistemas pueden ser consultados en el listado de subsistemas que se abrirá a partir de una opción en el menu lateral izquierdo llamada "Subsistemas".

En este listado se mostrará la siguiente información: 

• Subsistema: Nombre del Subsistema
• Estado: Estado del Subsistema que podrá contener los valores Activo o Archivado
• Registros: Número de registros que coinciden con los subsistemas e incluye un enlace hacia un filtro de Jira donde se muestran todos los tiques que incluyen el subsistema correspondiente

 2.4.2 Creación de subsistemas

Los subsistemas de una aplicación/componente se tendrán que dar de alta en Jira a través de un tique del tipo "Tarea general" en el proyecto "Estela". Se debe incluir en la descripción la siguiente información:

• Aplicación: nombre y código de la aplicación en Jira
• Subsistema: Nombre de los Subsistemas que se necesitan. Se deben escribir de la siguiente manera: 
  • "SUBXXX - Nombre"
• Descripción: Breve descripción de los subsistemas.

Figura 5. Formulario de registros: Añadir subsistemas

2.5 Componentes

Para proyectos que siguen el modelo "Aplicación-Componente" se establecerán los componentes necesarios y se informarán tanto en los Casos de uso como en los Test. (Ver figura 6.1 y 6.2)

2.5.1 Listado de componentes

 Al igual que en los subsistemas, los componentes pueden ser consultados en un listado que se abrirá a partir de una opción en el menú lateral izquierdo llamada "Componentes".

En este listado se mostrará entre otra información lo siguiente: 

• Componente: Nombre del Componente.
• Estado: Estado del Componente que podrá contener los valores Activo o Archivado.
• Registros: Número de registros que coinciden con los componentes e incluye un enlace hacia un filtro de Jira donde se muestran todos los tiques que incluyen el componente correspondiente.
• Descripción: breve descripción del Componente

2.5.2 Creación de componentes

Los componentes de un proyecto que sigue el modelo "Aplicación-Componente" se tendrán que dar de alta en Jira a través de un tique del tipo "Subtarea general" en el proyecto "TRANSFOR" correspondiente. Se debe incluir la siguiente información:

• Tipo de Registro: por defecto aparece "Subtarea general"
• Asignar: seleccionar "Olimpia Torres Barranco" que pertenece al equipo de SSHH.
• Descripción: Nombre de los Componentes que se necesitan. Este nombre deberá comenzar por el nombre del proyecto.
• Prioridad: seleccionar la prioridad que debe tener la solicitud.

                                                  Figura 6.1. Componente(s) CUFigura 6.2. Componente(s) CP                                                                           

3.1 Flujo de trabajo de Test

Los estados de un "Test" son: "OPENED", "VIGENTE", "PARALIZADA(*)" y "CLOSED).

Cuando se crea el Test, su estado inicial será "OPENED".

A continuación, será necesario actualizar los siguientes campos:

• Componentes: seleccionar componente del desplegable. Obligatorio para proyectos que siguen el modelo de gestión aplicación-componentes.
• Subsistemas: subsistema funcional al que pertenece el Test. Ver apartado 2.4.1.
• Subtipo test : tipo de tests según el enfoque específico del mismo. Ver anexo II.
• Etiquetas: ver apartado 3.5.
• Asignado: dejar con el valor que tiene por defecto ("sin asignar").
• Estado: dejar el Test en estado "ABIERTA"
• Tipo: el que corresponda (Manual, Automated (Cucumber))

Una vez que la primera PLH (PL Versión Hija) llegue a estado "CERRADA" con resolución "RESUELTA", el Test pasará automáticamente al estado "VIGENTE" y se actualizarán los campos "Versión Afectada" y "Versión Correctora".

En caso de que los pasos descritos en el Test queden obsoletos, el Proveedor podrá cerrarlo pasando al estado "CERRADA" con resolución "Deprecada".

El estado PARALIZADA solamente es usado por el equipo de la OCA.

3.2 Creación de test

La creación de un test se hará directamente desde el propio caso de uso, puesto que los test están directamente relacionados con los criterios definidos en ese espacio, entonces, hay una opción "Nuevo Test" dentro del tique el cual abrirá un formulario de registro con el tipo "Test" asignado.

Los campos que hay que definir son los siguientes:

• Proyecto* (Esta información se completa de forma automática)
• Tipo de Registro* (hay que seleccionar el tipo "Test")
• Pestaña "General":
  • Título. Se detalla a continuación la nomenclatura que debe seguir este campo según el tipo de Test:
    • Funcional: CPYYY-XXX - Nombre (YYY coincidirá con el número asociado al subsistema al que pertenece el caso de prueba (SUBYYY - Nombre), XXX será un número de tres dígitos que no podrá repetirse).
      En el caso de no agrupar los casos de prueba por subsistemas se usará la notación habitual con sólo un nivel (CPXXX).
    • Funcional de Interoperabilidad (E2E): CPFIXXX - Nombre (XXX será un número de tres dígitos que no podrá repetirse).
  • Descripción: Además de una breve descripción de la funcionalidad a probar se deberá incluir el número del escenario o escenarios que cubre el Caso de Prueba.
  • Componentes
  • Subsistemas
• Etiquetas: ver apartado 3.5 con las etiquetas predefinidas. En este campo se decidirá si el Test formará parte de la regresión del proyecto, es decir, si debe ser ejecutado cada vez que se realice una entrega de la aplicación. De esta forma se podrá validar si las funcionalidades básicas siguen funcionando correctamente.
• Subtipo de Test: subtipo al que pertenece el Test (Funcional o End-To-End).
• Pestaña "Detalles de las pruebas":
  • Tipo de Test
    • Manual: Casos de prueba que se ejecutan paso a paso manualmente, definidos con pasos, datos de entrada, acciones esperadas, etc.
    • Cucumber: Casos de prueba definidos en lenguaje Gherkin (Given / When / Then).
    • Automated (Cucumber): Caso de prueba automatizada que combina características de los tests  con la estructura de pruebas en Gherkin (ver normativa en Automatización de pruebas funcionales)
    • Automated (Generic). Representa una prueba automatizada cuyos resultados provienen de herramientas o frameworks que no usan Gherkin o Cucumber. 

• • Pasos del Test (los siguientes campos solo se muestran cuando el "Tipo de test" es "Manual"):
    • Acción (obligatorio)
    • Datos (opcional)
    • Resultado Esperado (obligatorio)
    • Ficheros Adjuntos (opcional)
• Pestaña "Pre-Conditions":
  • Precondiciones (en caso de que aplique se registrarán todas aquellas precondiciones que deban cumplirse antes de ejecutar el Test)

3.3 Redacción de Casos de Prueba (Test Manual o Cucumber)

Los casos de prueba deben ser descritos garantizando que cada prueba sea comprensible, reproducible y ejecutable por cualquier tester, ya sea utilizando el tipo Test Manual o el tipo Test Cucumber e independientemente de su familiaridad con la aplicación o dominio funcional.

Pautas generales para ambos tipos de casos de prueba que se han de tener en cuenta en la redacción:

1. Escenarios claros y específicos. Describir pasos concretos y sin ambigüedad, que permita ejecutar la prueba sin apoyo adicional.
2. Escenarios autoexplicativos. Usar nombres de escenarios descriptivos, que indiquen claramente el objetivo del test.
3. Contexto. Se debe mencionar datos clave como roles, precondiciones, flujos previos necesarios, valores esperados. Incluirtablas para campos complejos.
4. Pasos reproducibles. Los pasos descritos deben poder seguirse fácilmente sin suposiciones.
5. Referencias. Incluir notas puede ayudar si hay aspectos no evidentes de la interfaz
6. Todos los requisitos indicados en el campo Requisitos de la Mejora deberán estar cubiertos con, al menos, un escenario
7. Documentar dependencias si existen. Si el test depende de datos cargados en el entorno, incluir una nota o comentario.
   • Ejemplo: # Requiere producto "AX123" previamente cargado en el sistema

3.4 Enlace de test

En ocasiones puede ocurrir que el caso de uso tenga algún tipo de relación con pruebas existentes o directamente modifican funcionalidades en tests ya existentes, en esos casos, en lugar de crear un test nuevo se enlazará al caso de uso. 

La opción de"+ Enlace" está justo al lado del botón "Crear Test" dentro del CU. Al seleccionar esta opción se abre una ventana que permite introducir el código de un tique de test o varios y al guardarlo quedan esos tests relacionados al CU. 

Es importante que se tenga en cuenta que un Test podrá estar enlazado con uno o varios CU sólo si estos pertenecen a la misma Mejora.

3.5 Repositorio de tests

Todos los tiques del tipo "Test" en Jira se gestionan a través de un plug-in llamado XRay. Este nos proporciona diferentes ventajas que ayudan a mantener un control sobre todo el proceso de testing. Una de estas ventajas es el repositorio de XRay donde se van a guardar los tiques creados del tipo "Test" y donde se van a poder organizar.

Empezando por lo básico, este repositorio está disponible desde el menu lateral izquierdo de Jira o desde el menu en la cabecera abriendo las opciones de "Test".

Figura 7: Opción "Añadir Tests" en un Caso de uso

Figura 8: Añadir Tests existentes en un Caso de uso

Figura 8. Acceso al repositoria de XRay desde el menu lateral

Figura 9. Acceso al repositoria de XRay desde la cabecera