 |
| iStockPhoto / Hong Li |
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.
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.
¿Y qué opinas tú?
«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.
¿Y qué opinas tú?
¿Cuál es el procedimiento de gestión de incidentes de software utilizado en tu empresa? ¿Utilizas una herramienta de sistema de seguimiento de incidentes? ¿Cuál es el mayor reto de llevar un buen proceso de gestión de incidencias?
Te invitamos a dejarnos comentarios en la Web de La Oficina de Proyectos de Informática (pmoinformatica) (Si lo deseas, puedes firmar tu comentario con la dirección de tu web).
¿Buscas más información de gerencia informática?
¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de gerencia informática?, entonces presiona "suscríbete" a continuación.
También puedes seguirnos vía Twitter, Facebook o Linkedin:
Referencia
Toledo, F. The Most Common Mistake in the Bug Life Cycle. DevOps Zone
Artículos similares
> 10 Tipos de pruebas no funcionales de software
> 10 pasos para elaborar el plan de pruebas de software
> La definición de pruebas de caja negra del ISTQB
> Tipos de pruebas de aplicaciones para celular
> Ambientes de pruebas de software: Buenas prácticas
> Los pasos para resolver incidencias en el período de estabilización
No hay comentarios :
Publicar un comentario