Guía de reporte de incidentes - proyectosuniandes/Proyecto-MISO4208 GitHub Wiki
PROPÓSITO
Mantis es la herramienta definida para la gestión de tareas entre un equipo de trabajo para encaminar problemas, testear soluciones, registrar histórico de alteraciones y gestionar equipos remotamente. Permite al equipo de calidad y usuarios de una aplicación o de un sitio Web informar a los desarrolladores los errores, sugerencias de mejora o cambios nuevos, encontrados en el transcurso de la prueba. Cada error puede ser plenamente documentado y su resolución seguida día a día en función de los datos aportados por los desarrolladores en Mantis.
REPORTE DE HALLAZGOS.
INGRESAR AL BUG TRACKER
Ingresar al sistema mantis, el usuario y la clave se solicita al administrador de la herramienta:
REPORTAR EL INCIDENTE
Para el reporte de incidentes se siguen los siguientes pasos:
- Seleccionar el proyecto – Previamente parametrizado.
- Seleccionar la opción “Reportar Incidencia”
- Seleccionar la Categoría
- Reproducibilidad: Este campo hace referencia si la incidencia encontrada siempre es reproducible, a veces, aleatoria, no se ha intentado, no reproducible o desconocido,
- Severidad: Es el impacto que tiene la incidencia sobre la aplicación que se está realizando.
- Seleccionar Prioridad (baja, media, alta, inmediata). Donde ** Baja: Son errores de diseño, presentación ** Normal: Son errores en opciones que no intervienen con el Core del negocio (Maestros, reportes) ** Alta: Son los errores con el core del negocio. ** Urgente o Inmediata: Son los errores stoper, que no dejan continuar con la prueba de la funcionalidad.
PLATAFORMA: SE DESCRIBE EN QUE NAVEGADOR O DISPOSITIVO SE PRESENTO LA INCIDENCIA.
- SO: Es el sistema operativo del servidor donde está instalada la aplicación el cual puede ser pruebas, desarrollo o producción.
- Seleccionar la versión del producto: Versión actual de la aplicación que está presentando el defecto. NOTA: es muy importante especificar la versión del producto, ya que proporciona una gran referencia para el desarrollador.
- Seleccionar Asignado A: Se selecciona el nombre del encargado.
- Previsto para versión: Se selecciona producción, pruebas o desarrollo, es donde, se verificara el resultado correcto de la incidencia.
- Resumen: Se describe el título de la incidencia. Permita ubicar rápidamente al usuario sobre de lo que se trata la incidencia: Nombre del modulo_Opción_Incidencia
- Descripción: Es la narración de los hechos, la forma en que se presentó la incidencia, una descripción muy detallada que permita recrear la manera en que se produjo el error. Escribir la estrategia y prueba que se estaba ejecutando, así como el script utilizado, que se esperaba que pasara si no se hubiera presentado el error, cuantas veces paso, que mensaje obtuvo del error.
- Pasos para reproducir: Son los pasos que deben de seguir el usuario para llegar al incidente. Es decir se describen los pasos del caso de prueba y el resultado que da el sistema y el resultado esperado. Es necesario identificar la estrategia, la prueba, que tipo y modo de prueba se ejecuto y los scripts o la semilla utilizada para la prueba.
- Información Adicional: Cualquier información extra que no se ingresó en la descripción, debe ir aquí, puede ser un arreglo propuesto, una teoría acerca de porque ocurrió el error. Cualquier cosa que se relacione directa o indirectamente con el bug.
- Seleccionar el ciclo de pruebas (Ciclo1, Ciclo2, Regresión y revisión)
- Seleccionar la funcionalidad del aplicativo en el cual se encontró el incidente.
- Subir Archivo: Permite subir una imagen del incidente captada en la pantalla o archivos resultados de la funcionalidad probada. estos pueden ser tomados desde S3.
- Visibilidad: Permite determinar el acceso al incidente de acuerdo al rol (nivel de acceso) que tenga cada usuario. Los incidentes que son públicos los pueden ver todos los usuarios del proyecto. Los incidentes que son privados solo pueden ser vistos por los desarrolladores, administradores y equipo de calidad. Nota: Si el incidente que se va reportar ya está reportado, se adiciona una nota donde se indique que el bug tiene que ver con el bug ya reportado, no es conveniente reportar bugs duplicados.