La falla más frecuente en los sistemas de seguimiento de incidentes de software

En la actualidad, los desarrollos de software cada vez se hacen más cortos, iterativos y con cambios de alcance sobre la marcha, por lo cual es imperativo contar con un proceso y sistema de seguimiento de incidentes que pueda identificar y corregir los errores de software en el menor tiempo posible.

Cuando los Testers de software y los desarrolladores trabajan en equipo, el tiempo transcurrido entre la identificación y corrección de errores en las pruebas de software puede reducirse al mínimo.

A pesar que los errores en el software no se pueden prevenir nunca al 100%, se pueden aplicar buenas prácticas para que los errores en el software tengan un tiempo de vida corto y además que no se multipliquen.

Te has preguntado ¿Cuál es el error común que se comete en la corrección de incidencias? o  ¿Cuál es la falla más persistente en los sistemas de seguimiento de incidentes?, te contamos a continuación.

El ciclo de vida de una incidencia

Comentando acerca de lo que es un sistema de seguimiento de incidentes para las pruebas de software, la siguiente gráfica presenta un flujograma del ciclo de vida de un error de software (Un bug) y los diferentes estados por los que transita durante su tiempo de vida.

Este proceso genérico describe la mayoría de las situaciones, un buen sistema de gestión de incidentes debe manejar los errores de software bajo el siguiente procedimiento:

• Los errores de software son identificados durante las pruebas de software y registrados en el sistema por el Tester de Software (Nuevo). Es en este momento cuando se reporta el error.

• El equipo de desarrollo toma el incidente y comienza a analizarlo (Abierto).

• Se asigna el incidente a un desarrollador (Asignado).

• Si el incidente no aplica, puede clasificarse como Rechazado.

• Si el incidente aplica, pero es de bajo impacto o existe otra condición que impida su corrección inmediata, puede pasar a diferido.

• Una vez corregido, en incidente es retornado al equipo de Testers de software (Volver a probar).

• Si el equipo de Testing observa que no se ha corregido, puede clasificarlo como "Reabierto".

• Si la prueba es exitosa se clasifica como "Verificado".

• Luego de una revisión supervisora en el equipo de Testing, puede clasificarse como "Cerrado".

Este ciclo de vida se aplica bien a un proyecto de desarrollo de software que está en etapa de desarrollo (aún no está en ambiente de producción). Para el caso de incidencias en el período de estabilización o sistemas que ya están en producción, el ciclo de vida es similar, sólo que los tiempos de respuesta son más exigentes.

La falla más común en los sistemas de seguimiento de incidencias

«Uno de los errores más comunes en la gestión de incidentes es cuando un error (Bug) es corregido por el desarrollador y marcado como cerrado», asegura Federico Toledo, COO de Abstracta, quien añade que «Una vez que el error es marcado como cerrado, no debe olvidarse hacer una doble revisión de los incidentes, la persona que debería tener la última responsabilidad en determinar si ha sido resuelto es el tester que lo reportó en primer lugar».

Continua Federico Toledo, « ¿qué ocurre si al corregir un error se crean otros nuevos? El Tester de software debería siempre revisar que el mismo error ya no se están presentando e inclusive otros errores que pudieran haber surgido»

La complejidad de las pruebas de verificación de software

Realizar las pruebas de verificación de software debe ir más allá de simplemente tomar la misma funcionalidad y repetir la misma prueba de software (con los mismos datos de pruebas), debido a que pueden existir errores emergentes en la misma funcionalidad con otros datos de entrada, e inclusive en otras funcionalidades del sistema.

Para diseñar adecuadamente las pruebas de verificación, es necesario tener un conocimiento de la arquitectura del software, para así poder identificar cuáles componentes del sistema pueden verse afectados al realizar una modificación de programa.

Por ejemplo, en una arquitectura cliente servidor y multicapa (como se presenta en las aplicaciones web), si como resultado de una corrección se modificará un procedimiento de base de datos o un servicio web de la capa de negocio, no sólo deberá verificarse la funcionalidad donde el Tester de software identificó el error, sino también todas las demás funcionalidades de Front-End que usan el mismo procedimiento de base de datos o servicio web.

En estos casos, es importante la comunicación entre el equipo de pruebas con el equipo de desarrollo, así como también con el arquitecto de software. El equipo de desarrollo y el arquitecto pueden asistir al Tester de software en la identificación de otras funcionalidades (además de la que originó el error) deben probar, dadas las modificaciones realizadas en el desarrollo de software.

Inclusive, durante las pruebas de verificación pueden estipularse otros tipos de pruebas de software distintos al de la prueba original que identificó la incidencia.