Ciclo de vida defectuoso / con errores en las pruebas de software

El número de estados culpables varía de un proyecto a otro. Debajo del diagrama de ciclo de vida, cubre todos los estados posibles

• Nuevo: Cuando se registra y publica una nueva falla por primera vez. Se le asigna un estado como NUEVO.
• Sannta: Una vez que el probador publica el error, el líder del probador lo aprueba y lo asigna al equipo de desarrolladores.
• Abierto: El desarrollador comienza a analizar y a trabajar para corregir los defectos.
• Reparado: Cuando un desarrollador realiza un cambio de código necesario mientras verifica el cambio, puede establecer un estado de error como «Corregido».
• Revancha pendiente: Una vez que se corrige la falla, el desarrollador le da al probador un código para volver a examinar el código. Dado que la prueba del software aún está pendiente desde el final de los probadores, el estado asignado es «revisión pendiente».
• Repite: Un evaluador vuelve a verificar el código en este punto para verificar si el desarrollador ha solucionado la falla o no y cambia el estado a «Volver a probar».

• Verificado: El probador vuelve a probar el error después de que el desarrollador lo corrige. Si no se detecta un error en el software, el error se corrige y el estado asignado se «verifica».
• Reapertura: Si el error persiste incluso después de que el desarrollador lo haya solucionado, el evaluador cambia el estado a «reabrir». Una vez más, el error pasa por el ciclo de vida.
• Cerrado: Si el error ya no existe, el evaluador asigna el estado «Cerrado».
• Duplicar: Si la falla se repite dos veces o si la falla corresponde al mismo concepto de error, el estado cambia a «duplicado».
• Rechazado: Si el desarrollador considera que la falla no es real, cambia la falla a «denegada».
• Diferido: Si el error actual no es de máxima prioridad y se espera que se solucione en el próximo número, estos errores se asignan al estado «Diferido».
• No es un error: Si no afecta la funcionalidad de la aplicación, el estado asignado a un error es «Sin error».

Explicación del ciclo de vida defectuoso

1. Un probador encuentra la falla
2. Estado de fallo asignado: nuevo
3. La falla se envía al Gerente de Proyecto para su análisis.
4. El Project Manager determina si una falla es válida
5. Aquí la falla no es válida – se le da un estado «Rechazado».
6. Entonces, un gerente de proyecto asigna el estado rechazado. Si la falla no se rechaza, el siguiente paso es verificar si está dentro del alcance. Suponga que tenemos otra función de correo electrónico para la misma aplicación y tiene un problema con eso. Pero no es parte de la versión actual donde dichos defectos se asignan como pospuesto o pospuesto estado.
7. Luego, el gerente verifica que se haya planteado anteriormente un defecto similar. Si es así, a la falla se le asigna un estado duplicar.
8. De lo contrario, la falla se asigna al desarrollador que comienza a corregir el código. Durante esta etapa, a la falla se le asigna un estado en curso.
9. Una vez que se establece el código. A tu culpa se le asigna un estado reparado
10. Luego, el probador volverá a probar el código. Donde el Caso de prueba La falla pasa cerrado. Si los casos de prueba vuelven a fallar, es culpa reapertura y asignado al desarrollador.
11. Considere un caso en el que se encontró una falla en el pedido de fax durante la primera liberación de una Reserva de vuelo que se solucionó y se le asignó el estado cerrado. Durante la segunda versión de actualización, se resurgió el mismo defecto. En tales casos, habrá una falla cerrada. reapertura.

Eso es todo con Bug Lifecycle

Este video de capacitación describe las distintas etapas del ciclo de vida de una falla y su importancia con la ayuda de un ejemplo.