Historial de página
Subdirección de las Tecnologías de la Información y Comunicaciones
Área de Gobernanza y 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.
| Expandir | ||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||
Introducción
La Oficina de Calidad de la STIC utiliza JIRA como herramienta de trabajo para la gestión los servicios de calidad y verificación del software. El acceso directo a esta herramienta facilita la interacción tanto con jefes de proyecto de la STIC como con los proveedores de desarrollo.
La configuración actual de esta herramienta permite realizar un seguimiento completo del ciclo de vida del software, proporcionando mecanismos prácticos que permitan conocer en cada momento el grado de avance de los ciclos de pruebas, el resultado de los mismos y la generación de los informes que sean necesarios.
A continuación se realiza una pequeña descripción sobre los diferentes tipos de entidades existentes en JIRA relacionados con la gestión de pruebas y sus prioridades, así como un breve resumen del ciclo de vida de las "No conformidades".
Se entiende como No conformidad cualquier error, carencia o incumplimiento de un requisitos ya preestablecido.
Tipos de entidades relacionados con la gestión de errores
Dentro de la herramienta JIRA nos podemos encontrar con los siguientes tipos de incidencias:
| Tipo de incidencia | Tipo de incidencia | Descripción |
|---|---|---|
| Mejora | Representa mejoras a implementar por el proveedor en posteriores entregas de acuerdo con el Jefe del Proyecto. | |
| Historia | Representa los requisitos funcionales asociados a un sistema de información y registrados previamente en EA. |
 | Bug | Representa un error detectado en una fase temprana del desarrollo previa a la implantación del producto en un entorno preproductivo de la STIC. |
 | Caso de uso | Representa los casos de uso del sistema registrados. |
| No conformidad | Representa los posibles defectos detectados durante la ejecución de los planes de pruebas en un entorno preproductivo de la STIC. | |
| Incidente | Indica un evento inesperado que afecta al progreso de una tarea. |
 | Test | Representa un Caso de Prueba en JIRA. |
 | Test set | Representa una agrupación de casos de prueba en JIRA. |
 | Test plan | Representa el plan de pruebas relacionado con el aplicativo, englobando todos los casos de pruebas a ejecutar. |
 | Test execution | Representa una instancia de ejecución del plan de pruebas (Test Plan). |
 | Pre-condition | Representa la precondición necesaria para poder ejecutar un caso de prueba. |
Tipos de "No conformidades"
Se deberá seleccionar uno de los siguientes tipos según el tipo de la NC:
- Funcional
- Técnica
- De regresión
- Documental
- Accesibilidad
| Nombre | Descripción |
|---|---|
| Bloqueadora | El error detectado impide continuar el ciclo de pruebas . El impacto es tal que el aplicativo no podría pasar a producción. |
| Crítica | Fallos que son de carácter crítico para la funcionalidad principal y para los cuales no hay workaround. Conllevan un riesgo asociado. |
| Alta | Errores que afectan a la funcionalidad principal del aplicativo, pero no es obligatorio que sean resueltos antes de la entrega del producto a los usuarios finales. Deben resolverse en el siguiente evolutivo o correctivo que se entregue. |
| Media | Errores que no afectan a funcionalidades críticas para el usuario. El error habitualmente dispone de workarounds que permiten a los usuarios completar la tarea deseada aunque el error obstaculiza completarla o lo hace de un modo degradado. |
| Baja | Errores que no interfieren en el funcionamiento principal del aplicativo, aunque generan molestias que pueden ser o no resueltas. |
Ciclo de vida de una "No conformidad"
Estado | Descripción | Responsable |
IDENTIFICADA | La incidencia está abierta y lista para enviar al responsable para que la analice. | OCA / JP / Funcional |
PENDIENTE DE ANÁLISIS | Refiere un estado de revisión dónde el Coordinador OCA / JP ha solicitado al proveedor una confirmación de la aceptación del error. Indica que el error ha sido notificado al proveedor y se espera la aceptación o rechazo del mismo. | Proveedor |
PENDIENTE DE RECHAZO | El Coordinador OCA y/o JP revisan el error propuesto para rechazo. LA OCA podrá avanzar el estado una vez se recibe feedback por parte del Proveedor / JP. | Coordinador OCA / Funcional |
PENDIENTE INFORMACIÓN | Estado mediante el cuál se le requiere más información al técnico de la Oficina de Calidad o Funcional que registró el defecto en la herramienta o al proveedor. | Informador |
DISPUTADA | Estado final de la incidencia asignado por la propia Oficina de Calidad para aquellos defectos en los que no existe un entendimiento entre todos los actores implicados en el flujo. | Coordinador OCA |
| PENDIENTE DE REVISIÓN | Estado en el que se requiere al JP / Funcional que acepte la NC o en el caso contrario, que se proponga para rechazo. | Funcional |
| BACKLOG | Indica que la no conformidad se ha llevado a la cola de implementación para futuras entregas. |
Responsable del producto | ||
RECHAZADA | Se acuerda finalmente que la implementación era correcta. La organización indica que está lista para el cierre. | Coordinador OCA |
ACEPTADA | Refiere el estado en que se asume y reconoce la no conformidad. | Proveedor |
EN DESARROLLO | La no conformidad se encuentra en proceso de implementación por parte del proveedor. | Proveedor |
PARALIZADA | Se paraliza temporalmente la no conformidad. | Proveedor |
| EN TESTING | La no conformidad se encuentra en la fase de pruebas por parte del proveedor. | Proveedor |
PENDIENTE DE VALIDAR | Indica que la incidencia se encuentra en espera de validación por la OCA y/o JP. | Informador |
VALIDADA | Estado del defecto una vez corregido y validado por la OCA y/o JP | Responsable del producto |
| CERRADA | Estado final del defecto una vez implantado. | JP |
Las No conformidades detectadas en la revisión de la entrega en curso, cuya resolución se decida abordar por parte de la jefatura de proyectos de las STIC en futuras versiones, éste las ha de sacar de la versión cambiando el estado de las mismas a "Backlog".
Flujo de las acciones a ejecutar
A continuación se indica un flujo con las acciones que se pueden ejecutar desde cada estado:
| Estado inicial | Transición | Estado final | Actor ejecutor | Nuevo responsable | Comentarios |
|---|---|---|---|---|---|
| - | Creación | IDENTIFICADA | OCA / JP/ Funcional / Proveedor / Coordinador | OCA / JP | |
| IDENTIFICADA | Analizar | PENDIENTE DE ANÁLISIS | Coordinador / JP / Funcional / Coordinador OCA | Proveedor | Una vez verificada la incidencia por el test manager como un error del sistema, se envía la incidencia a revisión por parte del proveedor de desarrollo. |
| IDENTIFICADA | Rechazar | PENDIENTE DE RECHAZO | Coordinador OCA | Coordinador OCA / Funcional | Una vez analizada la incidencia abierta por el test manager, ésta es devuelta al tester y propuesta para rechazar ya que la incidencia abierta es errónea. El nuevo responsable es:
|
| PENDIENTE DE ANÁLISIS | Aceptar | ACEPTADA | Proveedor | Proveedor | El proveedor analiza la incidencia y la acepta como tal. Se mantiene como responsable el proveedor quién abordará su resolución. |
| PENDIENTE DE ANÁLISIS | No aceptar | PENDIENTE DE RECHAZO | Proveedor | Coordinador OCA / Funcional | Una vez analizada la incidencia abierta por el proveedor de desarrollo, ésta es devuelta al tester y propuesta para rechazar ya que la incidencia abierta es errónea. El nuevo responsable es:
|
| PENDIENTE DE ANÁLISIS | Solicitar información | PENDIENTE INFORMACIÓN | Proveedor | Informador | En el caso de que tanto el proveedor de desarrollo o el JP consideren que tienen poca información para poder evaluar la incidencia, podrán utilizar esta transición para solicitar más información al responsable asignado incluyendo en los comentarios los detalles necesarios. |
| ACEPTADA | Comenzar resolución | EN DESARROLLO | Proveedor | Proveedor | A través de esta transición el proveedor indicará a la OCA y JP que la incidencia está siendo abordada para incluirla en la próxima entrega de versión del producto como resuelta. |
| BACKLOG | Asignar versión | ACEPTADA | JP / Coordinador | Proveedor | El proveedor o el jefe de proyecto incluye en una versión la incidencia del backlog de trabajo pendiente. |
| EN DESARROLLO | Probar | EN TESTING | Proveedor | Proveedor | A través de esta transición el proveedor indicará a la OCA y JP que está verificando la corrección de la incidencia antes de darla como resuelta. |
| EN DESARROLLO | Paralizar | PARALIZADA | Proveedor | Proveedor | El desarrollo de la corrección de una incidencia se ha paralizado, el proveedor ha de informar de la causa. |
| EN DESARROLLO | No resolver | ACEPTADA | Proveedor | Proveedor | Esta transición la utiliza el proveedor de desarrollo cuando está abordando la resolución de una incidencia y detecta que el alcance de la misma tiene un mayor cuLa corrección de una incidencia en desarrollo |
| PARALIZADA | Reanudar | EN DESARROLLO | Proveedor | Proveedor | Se reanuda por parte del proveedor el desarrollo para la resolución de la incidencia. |
| EN TESTING | Resolver | PENDIENTE DE VALIDAR | Proveedor | Informador | Una vez que el proveedor de desarrollo a terminado todos trabajos referidos a la entrega de una nueva versión del aplicativo, traslada la incidencia a la OCA y/o Funcional para que pueda verificar su resolución. |
| PENDIENTE DE VALIDAR | Validar | VALIDADA | OCA / JP | Responsable del producto | En el caso de que la OCA y/o el funcional verifiquen la correcta resolución de la incidencia abierta, pasará a cerrar la incidencia quedando ésta en un estado final. |
| PENDIENTE DE VALIDAR | No validar | ACEPTADA | OCA / JP | Proveedor | En el caso de que la OCA y/o Funcional consideren que el error sigue produciéndose tras la entrega de una nueva versión del producto, se informa nuevamente al proveedor de desarrollo de que la incidencia continúa reproduciéndose. |
| VALIDADA | Implantar | CERRADA | Responsable del producto | JP | Estado final. |
| PENDIENTE DE RECHAZO | Aceptar rechazo | CERRADA | Funcional / Coordinador OCA / JP / Coordinador | JP | Estado final. Si el informador pertenece al equipo Funcional. |
| PENDIENTE DE RECHAZO | Aceptar rechazo | RECHAZADA | Funcional / Coordinador OCA / JP / Coordinador | Coordinador OCA | Estado final. Si el informador pertenece al equipo de la OCA. |
| PENDIENTE DE RECHAZO | Mover a mejora | BACKLOG | Funcional / Coordinador OCA/ JP | Proveedor | Transición utilizada por el JP cuando se acuerda entre todas las partes implicadas que el error detectado no es un error sino una mejora del sistema. |
| PENDIENTE DE RECHAZO | No aceptar rechazo | ACEPTADA | Funcional / Coordinador OCA / JP | Proveedor | El JP y/o OCA tras analizar la información del proveedor en la que propone a rechazo una incidencia, se verifica la incidencia como tal y la traslada de nuevo al proveedor. |
| PENDIENTE DE RECHAZO | Solicitar información | PENDIENTE INFORMACIÓN | Funcional / Coordinador OCA / JP | Informador | En el caso de que OCA y/o el JP consideren que tienen poca información para poder evaluar la incidencia, podrán utilizar esta transición para solicitar más información incluyendo en los comentarios los detalles necesarios. |
| RECHAZADA | Disputar | DISPUTADA | Coordinador OCA | Coordinador OCA | Esta transición la ejecutará únicamente la OCA para aquellos defectos en los que no existe un entendimiento entre todos los actores implicados en el flujo. |
| RECHAZADA | Aceptar rechazo | CERRADA | Coordinador OCA | JP | Mediante esta transición el test manager podrá rechazar de manera definitiva una incidencia abierta por alguno de los tester. La causa del rechazo debe quedar debidamente explicado en los comentarios de la incidencia. |
| DISPUTADA | Aceptar rechazo | CERRADA | Coordinador OCA | JP | Mediante esta transición el test manager podrá rechazar de manera definitiva una incidencia abierta por alguno de los tester. La causa del rechazo debe quedar debidamente explicado en los comentarios de la incidencia. |
| DISPUTADA | No aceptar rechazo | PENDIENTE DE ANÁLISIS | Coordinador OCA | Proveedor | Tras el análisis del test manager con el JP de una incidencia disputada, se verifica la misma y se traslada al proveedor. |
| DISPUTADA | Analizar | PENDIENTE DE RECHAZO | Coordinador OCA | Coordinador OCA / Funcional | Tras el análisis del test manager con el JP de una incidencia disputada, se propone para rechazo. El nuevo responsable es:
|
| PENDIENTE INFORMACIÓN | Completar información | PENDIENTE DE ANÁLISIS | Usuario asignado | Proveedor | El actor ejecutor es el informador si el estado de origen es PDTE. ANÁLISIS El actor ejecutor es el usuario seleccionado si el estado de origen es PDTE. RECHAZO |
| PENDIENTE INFORMACIÓN | Completar información | PENDIENTE DE RECHAZO | Usuario asignado | Coordinador OCA / Funcional | El actor ejecutor es el informador si el estado de origen es PDTE. ANÁLISIS El actor ejecutor es el usuario seleccionado si el estado de origen es PDTE. RECHAZO El nuevo responsable es:
|
| PENDIENTE INFORMACIÓN | Revisar | PENDIENTE DE REVISIÓN | Usuario asignado | OCA / Funcional | Esta transición la utiliza el usuario asignado para devolver la incidencia a OCA o JP una vez incluido en los comentarios la información que se solicitaba para poder realizar la revisión de la incidencia y evaluarla. El actor ejecutor es el informador si el estado de origen es PDTE. ANÁLISIS El actor ejecutor es el usuario seleccionado si el estado de origen es PDTE. RECHAZO |
| PENDIENTE DE REVISIÓN | Aceptar | ACEPTADA | Funcional / Coordinador OCA / JP / Coordinador | Proveedor | La OCA y/o JP una vez evaluada la incidencia con la información adicional aportada verifica que se de un error que requiere corrección. |
| PENDIENTE DE REVISIÓN | No aceptar | PENDIENTE DE RECHAZO | Funcional / Coordinador OCA / JP / Coordinador | Coordinador OCA / Funcional | La OCA y/o JP una vez evaluada la incidencia con la información adicional aportada se propone para rechazo. El nuevo responsable es:
|
Información relevante sobre el registro de defectos
ImpactoUna "No conformidad" tiene un nivel de prioridad que indica su importancia en función del impacto que tiene sobre el producto. Las prioridades definidas actualmente que informa la Oficina de Calidad están listadas más abajo.
Tipos de "No conformidades"
Se deberá seleccionar uno de los siguientes tipos según el tipo de la NC:
Versiones
| Campo versión | Descripción | Responsable incluir versión |
|---|---|---|
| ID Versión relacionada | Indicar en el campo "ID versión versión relacionada" la versión del aplicativo sobre la que se está trabajando (X.Y.Z) y que deberá estar declarada en Jira. Si el responsable del proyecto decide que la NC no se resolverá en la versión en progreso, éste desasignará la versión y la NC quedará en Backlog para ser abordada en próximas versiones. | Informador |
| Entrega en la que se detecta | Indicar la entrega de 4 dígitos del aplicativo (X.Y.Z.i). Esta información se trasladará de forma automática al campo "Entrega afectada". | Informador |
| Entrega en la que se corrige | Indicar la entrega de 4 dígitos del aplicativo (X.Y.Z.i) en la que se corrige la NC. | Proveedor |
| Entrega correctora | Esta información se recoge de forma automática desde el campo "Entrega en la que se corrige", que ha sido previamente rellenado por el proveedor. Si la NC se resuelve como No Favorable, este campo se vacía y se rellena el campo "Entrega Afectada" de forma automática. | OCA (Automático) |
Vista general
Herramientas de contenido
- Impreso por Atlassian Confluence 8.7.2