Ciclo de vida del defecto

Esta guía enumera las distintas fases del ciclo de vida del defecto por las que pasa.

Un defecto es un error o equivocación en una aplicación que hace que el sistema se comporte de forma diferente a lo que exigen los requisitos. Encontrar fallos o errores de la aplicación programada por los desarrolladores es el trabajo del equipo de pruebas.

El equipo de pruebas se asegura de que se encuentran todos los errores antes de que la aplicación salga al mercado o esté disponible para los usuarios finales.

¿Cuál es el ciclo de vida de un fallo o defecto?

El ciclo de vida de un fallo o defecto es el movimiento de un fallo o defecto a través de las distintas fases de su vida, desde el principio, cuando se identifica por primera vez, hasta el momento en que se marca como verificado y se cierra.

Dependiendo de la herramienta de gestión de fallos utilizada (como Bugzilla, Jira, etc.) y de los procesos seguidos por la organización, podemos tener distintos estados, así como distinta nomenclatura para los estados en el ciclo de vida de los fallos.

El ciclo de vida del defecto incluye los siguientes recursos:

• Comprobador – para encontrar el error y volver a comprobar el error resuelto.
• Jefe de Proyecto / Director de Proyecto / Jefe de Pruebas – Para verificar el fallo y asignarlo al desarrollador adecuado.
• Desarrollador – Para resolver un error o defecto notificado por un probador.

Ciclo de vida del defecto

A continuación se indican las distintas fases del ciclo de vida del defecto:

Nuevo

Cuando el probador encuentre un nuevo fallo/defecto, se publicará en el seguimiento de fallos con el estado «NUEVO». Se indicarán los pasos para reproducir el error y la gravedad del mismo, junto con una explicación del error.

Asignado

Cuando se informa de un nuevo fallo, el responsable o gestor correspondiente (jefe de proyecto/director de proyecto/director de pruebas) lo aprueba y asigna el fallo al desarrollador adecuado. Una vez asignado el fallo al desarrollador, su estado cambia a «ASIGNADO». Cuando se asigna un error, también se asigna su prioridad.

Abre

A veces, en cuanto se asigna un error a alguien, éste tiene un estado común, es decir j. «ABIERTO/ASIGNADO». A veces los dos estados son diferentes, por ejemplo, un fallo está abierto pero sin asignar, o un fallo está asignado pero no abierto. Cuando se asigna un fallo a un desarrollador y éste empieza a trabajar en él, su estado cambia a «ABIERTO».

Rechazado/No es un error/Desechado

Si el desarrollador o quien asigne el fallo/defecto (jefe de proyecto/líder de proyecto/líder de pruebas) determina que el fallo no es válido, se le da el estado «RECHAZADO».

Diferido (Aplazado)

A veces, a un fallo/defecto nuevo o asignado se le asigna el estado «Aplazado» en función de la urgencia y criticidad del fallo. La corrección de un error diferido se retrasará durante un periodo de tiempo (para futuras versiones de la aplicación).

Fijo/En pruebas/Completado

Cuando el desarrollador resuelve o arregla el fallo, su estado cambia a «ARREGLADO» y se asigna de nuevo al equipo de pruebas. Tras comprobarlo, si se resuelve, su estado cambia a «VERIFICADO», y si no se resuelve y el error persiste, su estado cambia a «REABIERTO».

Reabierto

Si el comprobador no está satisfecho de que se haya resuelto el problema, se asigna al error el estado «REABIERTO». De nuevo, el mismo ciclo de arreglar el fallo y asignarlo de nuevo al probador continúa hasta que el fallo está en estado «CERRADO».

Verificado (Verificado)

Si el comprobador considera que el error se ha resuelto tras la prueba, lo marcará como «VERIFICADO».

Cerrado

Una vez verificado el error, éste pasa al estado «CERRADO».