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.
Introducción
La Oficina de Calidad de la STIC utiliza como herramienta de trabajo interna una instancia de JIRA destinada específicamente a la gestión de las tareas 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 y exhaustivo de los diferentes ciclos de pruebas ejecutados durante el desarrollo de los Sistemas de Información, 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 issues existentes en JIRA y sus prioridades, así como un breve resumen de las más importantes.
Tipos de incidencias
Dentro de la herramienta JIRA nos podemos encontrar con los siguientes tipos de incidencias:
| Tipo de incidencia | Tipo de incidencia | Descripción |
|---|---|---|
 | Historia | Representa los requisitos funcionales asociados a un sistema de información y registrados previamente en EA. |
 | Requisito no funcional | Representa los requisitos no funcionales asociados al sistema y registrados en EA. |
 | Requisito de integración | Representa los requisitos de integración asociados al sistema y registrados en EA. |
 | Requisito de información | Representa los requisitos de información asociados al sistema y registrados en EA. |
 | Caso de uso | Representa los casos de uso del sistema y registrados en EA. |
 | Error | Representa los posibles defectos detectados por la OCA durante la ejecución de los planes de pruebas. |
| Incidente | Indica un evento inesperado que afecta al progreso de una tarea. |
 | Mejora | Representa aquellas posibles incidencias detectadas por la OCA durante la ejecución de los planes de pruebas, pero que debido al alcance de los mismos se consideran como mejoras a implementar por el proveedor en posteriores entregas de acuerdo con el Jefe del Proyecto. |
 | 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. |
 | Risk | Representa un riesgo detectado durante la ejecución del plan de pruebas y que será asociado a la issues que lo provoca. |
Una incidencia tiene un nivel de prioridad que indica su importancia. Las prioridades definidas actualmente, están listadas más abajo.
| Icono | 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 caracter 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. |
A continuación se detalla los flujos de las principales entidades a tener en cuenta por los proveedores de desarrollo y jefes de proyecto.
Ciclo de vida de los errores
| Estado | Descripción | Responsable |
|---|---|---|
ABIERTA | La incidencia está abierta y lista para que el responsable empiece a trabajar en ella. | OCA |
BUG - PENDIENTE DE APROBACIÓN | Refiere un estado de revisión dónde el Test Manager ha solicitado al proveedor una confirmación de la aceptación del error. Indica que el error ha sido notificado al proveedor y al JP y se espera feedback del mismo. | Proveedor / JP |
BUG - PENDIENTE DE RECHAZO | Estado que indica que la incidencia abierta por el tester durante un ciclo de pruebas ha sido propuesta para rechazo por el test manager, pudiendo el tester añadir nueva información sobre el error encontrado o cerrando definitivamente como rechazada la incidencia. | OCA |
BUG - NECESITA INFORMACIÓN | Estado mediante el cual se le requiere más información al técnico de la oficina de calidad o al proveedor. | OCA / Proveedor |
BUG - DISPUTADO | Estado final de la issue 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. | OCA |
TESTING | Estado que indica que el error detectado esta listo para verificar su subsanación por parte de la OCA. | OCA |
SELECTED FOR DEVELOPMENT | Indica que el defecto está incluido en una versión que se está desarrollando para su próxima entrega. | Proveedor |
REJECTED | Indica que el defecto detectado no es válido, se añadirá información adicional indicando el motivo de rechazo. | OCA |
BACKLOG | Indica que el defecto está registrado para su corrección en futuras entregas del aplicativo. | Proveedor / JP |
CANCELLED | Indica que el error ha sido cancelado por diversas causas ajenas al aplicativo, por ejemplo mal registro por parte del tester. | OCA |
LISTO | Estado final del defecto una vez corregido y validado por la OCA. | OCA |
A contiuación se indica un flujo con las acciones que se pueden ejecutar desde cada estado:
| Transición | Descripción | Estado inicial | Estado final | Actor que la ejecuta | Nuevo responsable de la incidencia |
|---|---|---|---|---|---|
| Proponer para aprobación | 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 JP y/o el proveedor de desarrollo. | Open | BUG - Pendiente de aprobación | OCA - Manager | Proveedor de desarrollo / JP |
| Proponer para rechazo | Una vez analizada la incidencia abierta por el test manager, esta es devuelta al tester y propuesta para rechazar ya que la incidencia abierta es errónea. | Open | BUG - Pendiente de rechazo | OCA - Manager | OCA - Tester |
| Retipificar incidencia | Transición utilizada por la OCA cuando se acuerda entre todas las partes implicadas que el error detectado no es un error sino una mejora del sistema. | Open | Done | OCA - Manager | - |
| Requerir información | 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. | BUG - Pendiente de aprobación | BUG - Necesita información | Proveedor de desarrollo o JP | OCA - Proveedor de desarrollo |
| Enviar información | El responsable de la incidencia a quién se solicita información añade las aclaraciones y/o evidencias que se le requieren y a través de esta transición avanza el estado de la incidencia. | BUG - Necesita información | Open | OCA / Proveedor de desarrollo | OCA - Proveedor de desarrollo |
| Trabajo pendiente | El prooveedor o el jefe de proyecto acepta la incidencia abierta por la OCA y la incluye en el backlog de trabajo pendiente. | BUG - Pendiente de aprobación | Backlog | Proveedor de desarrollo o JP | Proveedor de desarrollo |
| Incluir en la entrega | 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 | Selected for Development | Proveedor de desarrollo | Proveedor de desarrollo |
| Enviar a QA | 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 para que pueda verificar su resolución. | Selected for Development | Testing | Proveedor de desarrollo o JP | OCA |
| BUG - reentregar | En el caso de que la OCA considere que el error sigue produciéndose tras la entrega de una nueva versión del producto, se informa nuevamente al proveedor de desarrollo y al JP de que la incidencia continúa reproduciéndose. | Testing | BUG - Pendiente de aprobación | OCA | Proveedor de desarrollo / JP |
| Cerrar | En el caso de que la OCA verifique la correcta resolución de la incidencia abierta, pasará a cerrar la incidencia quedando ésta en un estado final. | Testing | Done | OCA | - |
| Revisar incidencia | Transición que facilita la reapertura de una incidencia que por alguna causa necesita ser reabierta. | Reopened | Open | OCA | OCA |
| Rechazar | Mediante esta transición la OCA 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. | BUG - Pendiente de rechazo | Rechazado | OCA | - |
| Disputar | Esta transición la ejecutará unicamente la OCA para aquellos defectos en los que no existe un entendimiento entre todos los actores implicados en el flujo. | BUG - Pendiente de rechazo | BUG - DISPUTADO | OCA | OCA |
Vista general
Herramientas de contenido
- Impreso por Atlassian Confluence 8.7.2