Cómo gestionamos los incidentes

¿QUÉ TIPOS DE INCIDENTES PODEMOS REPORTAR?

➢ Error: Un error es una acción humana que produce un resultado incorrecto o inesperado en el
software. Los errores son cometidos por los desarrolladores durante el proceso de creación del
software, como equivocarse en la implementación de una funcionalidad.
➢ Defecto: Un defecto es una imperfección o problema en el software que causa un comportamiento
incorrecto, inconsistente o no deseado. Los defectos son el resultado de errores en el código o en el
diseño del software y pueden ser detectados durante el proceso de testing.
➢ Fallo: Un fallo es la manifestación de un defecto en el software cuando se ejecuta en un entorno real
y produce un resultado incorrecto o no esperado. Un fallo ocurre cuando el software no cumple con
las expectativas o los requisitos establecidos y puede causar problemas para los usuarios finales.
➢ En cuanto a los "bugs", este término se utiliza comúnmente como sinónimo de defectos. En el
contexto del testing de software, un bug se refiere a un defecto encontrado durante el proceso de
pruebas. Los testers identifican y reportan bugs para que los desarrolladores los corrijan.
En resumen…

➢ Un error es una acción incorrecta o inesperada cometida por un

desarrollador.
➢ Un defecto es una imperfección o problema en el software causado por
errores en el código o el diseño.
➢ Un fallo es la manifestación de un defecto en el software durante su
ejecución real.
➢ Un bug es un término utilizado para referirse a un defecto encontrado durante
las pruebas.
¿Qué otros incidentes se reportan?... Mejoras
1. Mejoras en la usabilidad: Si identificas aspectos del software que podrían ser más intuitivos o fáciles de usar
para los usuarios, puedes sugerir mejoras en la interfaz de usuario, la navegación o las funcionalidades para
mejorar la experiencia del usuario.
2. Optimización del rendimiento: Si encuentras áreas en las que el software es lento, tiene tiempos de carga
prolongados o consume demasiados recursos, puedes proponer mejoras en el rendimiento para optimizar la
velocidad, la eficiencia y la capacidad de respuesta del software.
3. Corrección de defectos conocidos: Si eres consciente de defectos conocidos en el software que aún no han
sido solucionados, puedes recomendar su corrección para mejorar la calidad y la estabilidad del software.
4. Automatización de pruebas: Si identificas áreas en las que las pruebas manuales consumen mucho tiempo y
recursos, puedes sugerir la automatización de pruebas para mejorar la eficiencia y la cobertura de pruebas,
reducir los errores humanos y acelerar el ciclo de pruebas.
5. Mejoras en la documentación: Si encuentras deficiencias o falta de claridad en la documentación relacionada
con el software o el proceso de testing, puedes proponer mejoras en la documentación para facilitar la
comprensión y el uso del software.
6. Implementación de mejores prácticas de testing: Si observas que el equipo de testing no está siguiendo
ciertas mejores prácticas o metodologías, puedes recomendar la adopción de estas prácticas para mejorar la
calidad de las pruebas y los resultados obtenidos.
Categorías de incidentes - Ejemplos:
Funcionalidad: Esta categoría se refiere a problemas relacionados con el funcionamiento incorrecto o inesperado de las
funcionalidades del software. Puede incluir errores en la lógica de negocio, cálculos incorrectos, comportamiento incorrecto
de los botones o campos de entrada, entre otros.

Usabilidad: Esta categoría abarca problemas relacionados con la facilidad de uso y la experiencia del usuario. Puede incluir
aspectos como problemas de navegación, falta de claridad en las instrucciones, diseño confuso de la interfaz de usuario,
entre otros.

Rendimiento: Esta categoría se refiere a problemas relacionados con el rendimiento del software, como tiempos de
respuesta lentos, demoras en la carga de datos, consumo excesivo de recursos, entre otros.

Seguridad: Esta categoría abarca problemas relacionados con la seguridad del software, como vulnerabilidades, accesos no
autorizados, filtraciones de información confidencial, entre otros.

Compatibilidad: Esta categoría se refiere a problemas relacionados con la compatibilidad del software con diferentes
sistemas operativos, navegadores, dispositivos o configuraciones de hardware. Puede incluir errores específicos que
ocurren solo en ciertas plataformas o configuraciones.

Internacionalización y localización: Esta categoría abarca problemas relacionados con la adaptación del software a
diferentes idiomas, culturas y regiones. Puede incluir problemas de traducción, formato de fecha y hora, uso incorrecto de
caracteres especiales, entre otros.
Prioridad

La prioridad se refiere a la clasificación o la importancia relativa de un incidente,

tarea o problema en relación con otros elementos. Es un valor asignado para
determinar el orden de atención o resolución. La prioridad ayuda a establecer qué
problemas deben abordarse primero y cuáles pueden tratarse más adelante. La
asignación de prioridades se basa en la evaluación de factores como la gravedad, el
impacto y la urgencia.
¿Cómo asignar la prioridad?
Gravedad del problema: Evalúa cuán crítico es el incidente y qué tan severamente afecta el funcionamiento del sistema.
Un error que causa una interrupción completa del sistema o impide que los usuarios realicen funciones importantes
tendría una mayor gravedad.

Impacto en los usuarios: Considera el número de usuarios afectados por el incidente. Si un error afecta a muchos
usuarios o impide que realicen tareas críticas, es probable que deba tener una alta prioridad.

Urgencia: Evalúa cuán rápidamente el incidente necesita ser resuelto. Algunos problemas pueden requerir una solución
inmediata, mientras que otros pueden ser menos urgentes y permitir un tiempo de resolución más largo.

Reproducibilidad: Si el incidente se puede reproducir fácilmente y de manera consistente, es posible que tenga una
mayor prioridad, ya que será más fácil para los desarrolladores diagnosticar y solucionar el problema.

Impacto a largo plazo: Considera cómo el incidente puede afectar el sistema en el futuro si no se soluciona de
inmediato. Algunos problemas pueden tener consecuencias graves a largo plazo, lo que justificaría una prioridad más
alta.

Prioridades existentes: Si ya hay otros incidentes o tareas en la cola de prioridades, evalúa cómo se compara el nuevo
incidente en términos de gravedad y urgencia en relación con los existentes.
¿Cómo se clasifica la prioridad?
Prioridad basada en niveles
Alta: Incidentes críticos que afectan el funcionamiento básico del sistema o impiden a los usuarios realizar tareas esenciales.
Por ejemplo, el sistema no se inicia o los usuarios no pueden acceder a sus cuentas.
Media: Incidentes que tienen un impacto significativo, pero no crítico, en el sistema o los usuarios. Por ejemplo, una
funcionalidad importante no está disponible, pero hay alternativas o formas de trabajar alrededor del problema.
Baja: Incidentes que tienen un impacto menor o que no afectan directamente el funcionamiento principal del sistema. Por
ejemplo, errores estéticos o problemas que solo afectan a un número limitado de usuarios.
Prioridad basada en SLA (Acuerdo de nivel de servicio)
Urgente: Incidentes que deben resolverse dentro de un tiempo muy limitado debido a compromisos contractuales o acuerdos de
nivel de servicio. Por ejemplo, un error en un sistema de pago en línea durante las horas pico de compras en línea.
Alto: Incidentes que deben resolverse en un plazo razonable, pero que no son tan críticos como los urgentes. Por ejemplo, un
error en un formulario de contacto en un sitio web corporativo.
Normal: Incidentes que deben ser atendidos, pero pueden tener un tiempo de resolución más flexible. Por ejemplo, una solicitud
de mejora de una funcionalidad existente.
Prioridad basada en matriz de impacto y gravedad
Se crea una matriz que combina la gravedad del problema (alta, media, baja) y el impacto en el sistema o los usuarios (alto,
medio, bajo). Los incidentes se clasifican en función de su ubicación en la matriz, lo que determina su prioridad. Por ejemplo, un
incidente con alta gravedad y alto impacto tendría la máxima prioridad.
Severidad

La severidad se refiere al grado de impacto o gravedad de un incidente o problema

en términos de su efecto en el sistema o los usuarios. Indica la importancia relativa
del problema y la magnitud de su impacto. La severidad se evalúa teniendo en
cuenta los aspectos críticos o perjudiciales que puede generar, como la interrupción
del servicio, la pérdida de datos, el bloqueo del sistema, etc. La severidad ayuda a
comprender la gravedad del problema y su nivel de prioridad en el proceso de
resolución.
¿Cómo clasificar la severidad? #1
Severidad basada en niveles

Crítica: Incidentes que tienen un impacto devastador en el sistema y/o en los usuarios, impidiendo su uso
por completo. Por ejemplo, un error que causa la pérdida de datos importantes o un fallo total del
sistema.

Mayor: Incidentes que generan un impacto significativo en el sistema o en los usuarios, pero no impiden
su uso completo. Por ejemplo, una funcionalidad clave que no está disponible o un error que afecta
negativamente a un gran número de usuarios.

Menor: Incidentes que tienen un impacto menor en el sistema o en los usuarios y no impiden su uso
principal. Por ejemplo, errores estéticos o problemas que solo afectan a un número limitado de usuarios.
¿Cómo clasificar la severidad? #2
Severidad basada en el impacto en el negocio

Alto impacto: Incidentes que afectan directamente a la operación principal del negocio, generando
pérdidas financieras o daños significativos. Por ejemplo, un error en un sistema de comercio electrónico
que impide la realización de transacciones.

Impacto medio: Incidentes que tienen un impacto moderado en el negocio, pero no son críticos para su
operación principal. Por ejemplo, un error en una función secundaria del sistema que no afecta
directamente a los ingresos.

Bajo impacto: Incidentes que tienen un impacto mínimo en el negocio y no afectan significativamente sus
operaciones. Por ejemplo, errores menores en características no esenciales del sistema.
¿Cómo clasificar la severidad? #3
Severidad basada en la pérdida de funcionalidad

Pérdida crítica de funcionalidad: Incidentes que causan la pérdida total o significativa de una
funcionalidad clave del sistema. Por ejemplo, la incapacidad de guardar datos o enviar correos
electrónicos desde una aplicación.

Pérdida moderada de funcionalidad: Incidentes que causan la pérdida parcial o reducida de una
funcionalidad importante del sistema. Por ejemplo, la función de búsqueda de un sitio web que solo
devuelve resultados incorrectos en ciertos casos.

Pérdida mínima de funcionalidad: Incidentes que causan la pérdida de una funcionalidad menor o que no
afectan la funcionalidad principal del sistema. Por ejemplo, una característica adicional que no está
disponible temporalmente.
Pasos para la Reproducibilidad
Pasos detallados: Para ayudar a otros a reproducir el problema, se deben proporcionar pasos detallados y
claros sobre cómo se puede provocar. Esto incluye información específica sobre las acciones, entradas o
configuraciones necesarias para replicar el problema.
Datos de entrada: Si el problema está relacionado con una entrada de datos específica, es importante
proporcionar ejemplos o datos de muestra que muestren claramente cómo se debe estructurar o ingresar la
información para provocar el problema.
Ambiente de prueba: Se debe describir el entorno de prueba en el que se encontró el problema, incluyendo
información sobre la configuración del sistema, las versiones de software utilizadas, las dependencias, los
permisos de acceso, etc. Esto ayudará a asegurar que otros puedan recrear el entorno en el que ocurrió el
problema.
Captura de registros o evidencia: Si es posible, es útil capturar registros de error, mensajes de error, capturas
de pantalla o cualquier otra evidencia relevante que pueda respaldar la reproducción y análisis del problema.
Estos registros pueden proporcionar pistas adicionales sobre la causa subyacente del problema.
Intentos de reproducción: Otros miembros del equipo de desarrollo o pruebas pueden intentar reproducir el
problema siguiendo los pasos proporcionados y utilizando los datos de muestra. Si varios intentos conducen
a la reproducción exitosa y consistente del problema, se puede concluir que el problema es reproducible.
Categorías de Reproducibilidad
Reproducible: El problema puede ser replicado de manera consistente y confiable en
múltiples entornos y por diferentes personas. Los pasos para reproducir el problema son
claros y consistentes, lo que facilita su análisis y resolución.
Intermitente: El problema ocurre de forma ocasional o aleatoria, y no puede ser
reproducido de manera consistente en todos los intentos. Puede depender de
condiciones específicas, datos o factores desconocidos. La reproducibilidad intermitente
puede dificultar el análisis y la resolución del problema.
No reproducible: El problema no puede ser reproducido incluso después de múltiples
intentos. No se pueden encontrar patrones o condiciones específicas que permitan
recrear el problema. La falta de reproducibilidad puede complicar su análisis y
resolución, ya que es difícil determinar su causa subyacente.