Gestionando los Incidentes

Aprenderemos sobre la gestión de los incidentes 

Clasificando incidentes

Hay varias formas de clasificar los incidentes detectados.

Debemos establecer un criterio razonable de clasificación para poder comprender

mejor cada incidente, decidir qué corregir primero, qué se puede cambiar en el
desarrollo para evitar las tendencias existentes y comparar estadísticas de los
incidentes.

Los incidentes tienen distinto valor para los distintos actores involucrados en el
proyecto.

Tenemos que tener definidas distintas vistas de los incidentes, de forma de que
cada involucrado pueda obtener la información que busca dependiendo de su rol
en la organización.

¿Por qué es importante clasificar los incidentes?

Tener clasificados los incidentes nos ayudará a generar información para

poder responder preguntas como las mencionadas a continuación. 

Relativas a un incidente en particular, como por ejemplo:

 ¿Cuál es su impacto?
 ¿Qué tan a menudo sucede?
 ¿Cuánto esfuerzo se requiere para corregirlo?
 ¿Cuál es el riesgo de corregirlo?

Sobre el producto, como por ejemplo:

 ¿Cuánto falta por probar?

 ¿Ya está lista la versión para salir a producción?

Sobre los procesos, como por ejemplo:

 ¿Por qué estamos teniendo tantos ciclos de testing?

 ¿Por qué les está llevando tanto tiempo cada ciclo de testing?
 ¿Cuántos incidentes se detectan por versión? ¿Qué podemos hacer para
evitar algunos de estos incidentes?

Clasificación de los incidentes

Las respuestas relativas al producto podremos elaborarlas cruzando información
obtenida de la clasificación e información de estimaciones, planificación y
cubrimiento, entre otras fuentes relativas al contexto del proyecto.

Clasificamos a los incidentes por:

 Prioridad: Cuándo tiene que ser resuelto el incidente.

 Severidad: Impacto (técnico y en el negocio) y visibilidad si el incidente
ocurre.
 Categoría: Etiqueta genérica para un conjunto de incidentes que se
relacionan de cierta manera.

La severidad de los incidentes detectados es usualmente utilizada para medir la

calidad general del producto o de una funcionalidad particular.

La severidad es la que mide la importancia de un incidente, relativa a su impacto

en la calidad del producto o en la felicidad del usuario final que vaya a utilizar el
producto.

La prioridad no mide directamente el efecto sobre la calidad del producto.

Prioridad de cada incidente

La prioridad de un incidente indica cuán importante es para un actor del proyecto

que el incidente sea resuelto.

El actor involucrado dependerá de la etapa de desarrollo en la cual es detectado el

incidente.

Por ejemplo, si los incidentes son detectados en las pruebas unitarias, durante el
desarrollo, el líder determinará la prioridad, y si los incidentes son detectados en
etapas de testing, el cliente o algún gerente la determinarán.

La prioridad puede asignarse en función de otros atributos del incidente, como ser
la categoría, frecuencia y severidad entre otros.

Por ejemplo podríamos manejar las prioridades

 Baja: Aunque se ha detectado un incidente, el sistema puede seguir

funcionando y la solución puede investigarse más adelante.
 Media: Existe un incidente, pero se puede usar el sistema pues hay una
solución provisoria.
 Alta: Se ha detectado un incidente y no hay solución provisoria. Hay que
resolverlo rápidamente para continuar utilizando la funcionalidad.
 Urgente: no se puede continuar si no se corrige el incidente, ya que afecta a
una funcionalidad crítica.
  Inmediata: no se puede continuar con la ejecución. Si no se soluciona
rápidamente se verá afectado el negocio o alguna etapa del proceso o del
proyecto.

La prioridad del incidente depende del contexto.

El mismo incidente detectado en testing y en producción puede tener prioridades

distintas.

Por ejemplo si tenemos un sistema de facturación en producción, no se puede

imprimir una factura, y la operativa no prevé la emisión manual de facturas, se
reporta el incidente con prioridad “Inmediata”, ya que es una funcionalidad crítica
para el negocio.

Sin embargo si se detecta el mismo incidente, pero la operativa permite la

facturación manual, puede reportarse el incidente con prioridad “Media”, ya que el
negocio se ve afectado, pero es posible continuar con la operativa.

En otro contexto, si el mismo incidente es detectado en un ambiente de testing y

estamos en los primeros ciclos de prueba de la versión, podríamos reportarlo con
prioridad “Alta” y si estamos en el último ciclo de regresión podríamos reportarlo
como “Urgente”.

Severidad de un incidente

La severidad de un incidente depende del impacto que tiene sobre el dominio de la

aplicación y de cuán visible es para los usuarios. Es importante tener claro cómo
asignar la severidad.

En la severidad influyen varios elementos, pero consideramos que el impacto y

la visibilidad son los elementos más importantes.

 El impacto indica cuán perturbador es el incidente detectado para el trabajo

habitual del usuario que utilizara el producto bajo prueba.
 La visibilidad mide la probabilidad de que el incidente sea detectado por
un usuario habitual de la funcionalidad.

El impacto mide el efecto de un incidente en un usuario.

Indica cuánto interfiere al usuario en el desarrollo de una tarea o en su trabajo, así

como la dificultad para encontrar y usar caminos alternativos de ejecución (si
existen).

La visibilidad está relacionada con cuán cerca está el incidente del camino crítico
(funcionalidad central u operaciones claves) de la funcionalidad.
Puede ser también pensada como la probabilidad de que un usuario típico de la
funcionalidad se diera cuenta del defecto, o la frecuencia con la que los usuarios
verían el incidente. Por lo tanto la visibilidad de incidentes “intermitentes”
(aleatorios, no reproducibles, o producidos por factores desconocidos), desciende
en forma proporcional a su frecuencia.

En general, la clasificación de los incidentes de acuerdo a su severidad no se

modifica, salvo que al seguir investigando sobre el incidente, tratando de
reproducirlo, nos demos cuenta de que es más severo de lo que habíamos
considerado o al revés, menos importante de lo que pensamos en un primer
momento.

La severidad no es sólo una valoración, sino que ayuda a quien lo lee a

imaginar las consecuencias del incidente.

Existen varias jerarquías para definir los niveles de severidad, la mayoría están
basadas principalmente en el impacto, pero algunas también consideran la
visibilidad.

Básicamente, hay que manejar 3 categorías de severidad:

 Crítico: El defecto bloquea la operativa del software

 Mayor: El defecto puede causar salidas inesperadas si se produce
 Menor: El defecto puede causar problemas, pero no causa salidas
inesperadas

Pero podemos definir tantas categorías intermedias como consideremos necesarias.

Categorización de la severidad

Peter Farrell Vinay, en su libro “Manage Software testing”, propone 2

categorizaciones:

Categorización 1

Catastrófica: una falla que puede causar pérdidas de vida, dinero y/o perdidas de
sistemas de software.
Crítica: una falla que puede causar daños mayores, lesiones de vida y/o causar
daños mayores a sistemas de software.
Marginal: una falla que puede causar daños menores, lesiones menores de vida o
causar que sistemas de software tengan bajo rendimiento o disponibilidad
reducida.
Menor: una falla que no causa daños significativos o lesiones de vida ni daños
significativos a sistemas de software, pero que requiere corrección.
Categorización 2

Crítica: El incidente no permite que el usuario complete una tarea esencial.

Alta: Como crítica, pero existen alternativas.
Media: El incidente interfiere, pero no inhabilita funciones requeridas.
Baja: El incidente causa molestias en el equipo o clientes, pero no inhabilita el uso
de funcionalidades.

Prioridad y Severidad

La severidad de un incidente no determina la prioridad para su corrección.

Pueden haber incidentes que tienen una alta prioridad para ser corregidos y no son
severos.

Por ejemplo, en la aplicación que estamos probando hay un botón o un link que no
anda y hay que arreglarlo rápido para poder continuar probando, pero esta
incidencia no tiene un alto impacto sobre la funcionalidad que estamos probando.

Categoría de un incidente

Una categoría es una etiqueta genérica para un conjunto de incidentes que se

relacionan de cierta manera.

Un conjunto de categorías recibe de forma colectiva el nombre de "taxonomía".

Una taxonomía es una clasificación de elementos en un grupo ordenado o de

categorías que indican una relación de jerarquía natural.

En el libro “A Practitioner's Guide to Software Test Design” de Lee Copeland se

resumen varias de las taxonomías utilizadas.

Como ejemplo de taxonomía vamos a detallar la Taxonomía de Kaner, Falk, and

Nguyen's, en el libro “Testing Computer Software” se detallan 400 tipos de defectos
considerados en ésta taxonomía, a continuación listamos algunos de ellos:

Interfaz de usuario: funcionalidad, comunicación, estructurar de los comandos,

comandos faltantes, performance, salidas.

Manejo de errores: prevención de errores, detección de errores, recuperación de

errores.
Defectos relacionados a límites: límites numéricos, límite de tiempo o espacio,
límites de ciclos.

Cálculo: errores de cálculo, orden de operación incorrecto, overflow o underflow.

Estados iniciales y finales: falla al establecer el dato de un item a 0, falla al
inicializar una variable de control de un ciclo, falla al eliminar un string, falla al
reinicializar.

Errores de control de flujo: el programa no se comporta según flujo, el programa

se detiene, ciclos, IF THEN ELSE

Errores en el manejo o interpretación de datos: errores de tipo de datos, lista de

parámetros fuera de orden o faltantes, copias de datos desactualizadas, valores
incorrectos de tablas.

Hardware: dispositivos no disponibles.

Fuentes y control de versiones: incidentes antiguos reaparecen misteriosamente,

los fuentes no coinciden con los ejecutables, documentación.

Errores de testing

Categorías utilizadas en el CES

En el Centro de Ensayos de Software tenemos definida una taxonomía para los

incidentes detectados en pruebas funcionales y otra para las pruebas de
performance.

Usualmente se utilizan estas taxonomías en pruebas ejecutadas por un equipo de

testing independiente al equipo de desarrollo.

PARA PRUEBAS FUNCIONALES

La taxonomía utilizada usualmente por el Centro de Ensayos de Software para

pruebas funcionales tiene solamente un nivel. A continuación describimos cada
categoría que la compone:

 Error ortográfico
 Funcionalidad no disponible: Se aplica a incidentes ocurridos porque una
funcionalidad a probar (o necesaria para las pruebas), no está disponible
para su ejecución.
 Implementación incorrecta: Se aplica a incidentes cuyo resultado esperado
no coincide con el resultado obtenido al ejecutar uno o varios casos de
prueba.
 Instalación o ambiente: Se aplica a incidentes encontrados en la aplicación
ocasionados por problemas en la instalación de la versión o del ambiente en
el cual se ejecuta la aplicación.
 Interfaz de usuario: En esta categoría se encuentran los incidentes que
involucran la interfaz gráfica, parte de la interacción del usuario con el
 sistema. Ejemplos serían: la forma de ingresar los datos (tipos de datos),
interacciones, botones, imágenes, textos, vínculos (links), etc.
 Mejora: Son incidentes que destacan aspectos que podrían ser mejorados
en el producto.
 Manejo de errores: Se aplica a incidentes relativos a cómo se notifican y
despliegan al usuario los errores ocurridos. Considera la visualización y los
textos de los mensajes.
 Validación faltante / incorrecta: Se aplica a incidentes relativos a la no
validación de datos de entrada o de salida, o si se hacen validaciones que no
corresponden.
 Navegabilidad: Se aplica a incidentes debidos a dificultades, inconsistencias
y fallas en la navegación entre páginas, menús u otros elementos del
producto.
 Observación: Cuando el comportamiento observado no está especificado, y
debería ser diferente según el criterio de quien prueba.
 Salida anormal: Mientras se están ejecutando pruebas, se produce una
salida anormal de la aplicación. Incidentes de esta categoría pueden dejar
datos corruptos o pueden estar relacionados con una funcionalidad que no
cumple con su especificación.
 Seguridad: Se aplica a incidentes relativos a accesos que no deberían estar
permitidos o si se revela información confidencial, entre otros.
 Usabilidad: Se aplica a incidentes relacionados con la facilidad de uso,
aprendizaje y comprensión del producto.
 No clasificado: Incidentes que no corresponden a ningún nivel de la
taxonomía.

PARA PRUEBAS DE PERFORMANCE

La taxonomía utilizada usualmente por el Centro de Ensayos de Software para

pruebas de performance también tiene solamente un nivel. A continuación
describimos cada categoría que la compone:

 Bloqueos de tablas: Se aplica a incidentes ocurridos cuando diferentes

usuarios necesitan acceder al mismo recurso (por ejemplo, una tabla o
registro) de manera exclusiva. El primero que solicita el recurso logra
obtenerlo y lo bloquea para los demás usuarios.
 Falta de índices: Los índices pueden ayudar a mejorar el desempeño de
algunas transacciones sobre la base de datos. En esta categoría los
incidentes están relacionados a que si se definieran ciertos índices (aún no
definidos), mejoraría el desempeño del sistema.
 Configuración de máquina virtual: Lenguajes de programación altamente
difundidos como Java y .Net utilizan una máquina virtual para correr las
aplicaciones. Se aplica a incidentes debidos a la falta de optimización en la
máquina virtual, que de hacerse, mejoraría la performance del sistema.
  Algoritmos mal programados: Se aplica a incidentes relativos a que es
posible mejorar el desempeño del sistema si se re-programa o re-diseña
parte del sistema bajo prueba.
 Zonas de mutua exclusión: Las zonas de mutua exclusión establecen
secciones del código a las que no se puede acceder de manera concurrente.
Estas zonas pueden ocasionar deadlocks o problemas de desempeño.
 Mal dimensionamiento: Se aplica a incidentes relativos a que por más que
se realicen muchas mejoras sobre el sistema, el hardware que le da soporte,
no tiene la potencia necesaria para cumplir con los objetivos del sistema.

RESUMIENDO

No hay una taxonomía única que le sea útil a todas las organizaciones o a todos los
proyectos. Podemos tomar una de las taxonomías existentes como punto de
partida, y luego modificarla para que sea útil al momento de analizar los incidentes
para su corrección, y tomar las decisiones pertinentes en cada caso.

La taxonomía más útil es la taxonomía que tu creaste a partir de la experiencia

de tu organización. Lee Copeland

¿Para qué ayudan las taxonomías?

Las taxonomías ayudan a:

 Guiar las pruebas generando ideas para el diseño de casos de prueba

 Revisar el cubrimiento de los casos de prueba diseñados
 Comprender los defectos existentes
 Entender porqué se cometen ciertos errores en el proceso de construcción
del software
 Entrenar a nuevos testers respecto a las áreas que más necesitan pruebas y a
qué tipo de incidentes pueden ocurrir

Es importante destacar que podemos hacer testing de un software sin tener

definida una taxonomía, pero definirla nos ayudaría a estar atentos a aspectos que
de otra forma podrían pasarnos desapercibidos.

Cuando utilizamos una taxonomía para clasificar los incidentes, queremos que la
elección de una categoría, no represente tiempos significativos adicionales al
registro de los incidentes. Quienes reportan un incidente deberían poder indicar su
categoría sin mayores problemas.

Por esta razón se recomienda que:

 No se solapen ni repitan las categorías. O sea, que no existan ambigüedades

entre categorías.
  Se utilicen distintas taxonomías dependiendo de la etapa en la que se
registrarían los incidentes. Por ejemplo la taxonomía que utilice un equipo
de testers para pruebas puede ser más específica que la que utilizaría un
usuario para reportar un incidente detectado en producción.
 La taxonomía tenga pocas categorías. Cuando existen demasiadas
categorías, suele suceder que sólo se utiliza un subconjunto de ellas y no se
tiene claro cuándo corresponde cada una de ellas.
 Se defina una categoría “Otros” para cuando se detectan incidentes que no
pertenecen a ninguna otra categoría. Hay que controlar que no se abuse de
esta categoría y la idea es que tienda a desaparecer con refinamientos
sucesivos de la taxonomía.
 Se revisen periódicamente las categorías, y se detecten categorizaciones
erróneas de los incidentes con el fin de mejorar la calidad de los datos
registrados.

Obteniendo información de los reportes

¿Qué información queremos conocer?

Los incidentes aportan valor para los distintos actores involucrados en el proyecto.

Vamos a detallar qué información sobre los incidentes requieren los gerentes,
desarrolladores y testers para poder cumplir con sus tareas.

Recordemos que con las pruebas se brinda información a los distintos

actores involucrados en el proyecto sobre la calidad del producto que estamos
probando, para hacer posible la toma de decisiones pertinentes.

Dependiendo de la información obtenida se puede decidir  implementar el

producto nuevamente, corregir los incidentes o salir a producción sin corregirlos.

Información para los Gerentes

Los gerentes suelen realizarnos las siguientes preguntas:

 ¿Cuánto falta probar?

 ¿Ya está lista la versión para salir a producción?
 ¿Por qué está llevando tanto tiempo el testing?

Cuando nos hacen estas preguntas, requieren respuestas inmediatas, y no

tenemos tiempo de preparar y procesar información.

Tenemos que tener ordenados y clasificados los resultados de las pruebas para

generar esta información de forma semiautomática.
De la planificación, seguimiento y registro de ejecuciones e incidentes podemos
obtener información clara para que los gerentes puedan tomar decisiones.

La presentación de la información depende de la visión del gerente.

Distinguimos por lo tanto:

 Gerentes de primera línea, son las personas responsables del trabajo de las
demás personas.
 Gerentes medios, son las personas que dirigen las actividades de gerentes
de niveles más bajos y en ocasiones también las de empleados de
operaciones. Las organizaciones pueden tener varios niveles de gerentes
medios.
 Alta gerencia, es la responsable de administrar toda la organización,
reciben el nombre de ejecutivos.

Los gerentes de primera línea, usualmente están más involucrados en el proyecto

y el producto.

A los gerentes medios y a la alta gerencia es necesario mostrarles datos más

procesados y sin detalles que no aportan valor.

Información necesaria para que un gerente pueda decidir si se instala la versión en

el ambiente de producción:

 Información relativa al proceso de pruebas, conocer el cubrimiento en

extensión y profundidad.
 Cantidad de incidentes detectados sin corrección.
 Severidad de los incidentes detectados sin corrección.
 Categorización de los incidentes detectados sin corrección.
 Cantidad, severidad y categorización de los incidentes detectados por
módulo.

Información para el Equipo de Desarrollo

Dentro del equipo de desarrollo existen varios roles, un líder del equipo requerirá
conocer sobre los incidentes a ser corregidos en la próxima versión: cantidad,
severidad, categoría y módulos relacionados.

Un desarrollador del equipo, requerirá conocer información relativa al incidente

para poder analizarlo y corregirlo.

 Datos generales
o A quién está asignado el incidente
o Quién reportó el incidente
o Si ya tiene alguna resolución, cuál es
  Clasificaciones del incidente
o Categoría
o Reproducibilidad
o Severidad
o Prioridad
o Estado

 Información específica para reproducir el incidente

o Resumen
o Descripción
o Información adicional (capturas de pantalla, archivos con cálculos,
"stack traces")

 Información relacionada al incidente (contexto, ambiente)

o Versión del producto en que fue detectado
o Módulos con los cuales está vinculado el incidente
o Referencias a especificación de requerimientos o casos de uso
o Incidentes relacionados

Información para el Equipo de Testing

En el equipo de testing también existen varios actores y roles que requerirán

distinta información.

El líder del equipo testing necesitará conocer, para cada versión a probar:

 cantidad de incidentes corregidos

 cantidad de incidentes analizados por el equipo de desarrollo y que tienen
que ser revisados o aclarados por el equipo de testing
 versión en que serán corregidos los incidentes

Un tester necesita conocer el estado en que está cada incidente reportado para
poder hacerle seguimiento.