Ciclo de vida de errores en el desarrollo de software

Como sabemos, durante el desarrollo de cualquier producto de software, los equipos de desarrollo siguen los procesos del Ciclo de vida del desarrollo de software (SDLC) . Pero el proceso de desarrollo no es tan fácil y siempre funciona sin problemas. Durante el proceso de desarrollo, cuando se desarrolla el producto, surgen diferentes tipos de defectos o errores con el producto. Por lo tanto, estos defectos se identifican y resuelven a lo largo del proceso de desarrollo solo para entregar finalmente un producto de software de buena calidad. Entonces, en este artículo, discutiremos estos errores en el proceso de desarrollo de software y cómo se identifican durante las pruebas de software y cómo se resuelven.

¿Qué es un error/defecto?

Un defecto es un error o falla en una aplicación que se crea durante la construcción o el diseño de un software y debido al cual el software comienza a mostrar comportamientos anormales durante su uso. Por lo tanto, una de las responsabilidades importantes del probador es encontrar la mayor cantidad posible de defectos para garantizar que la calidad del producto no se vea afectada y que el producto final cumpla perfectamente con todos los requisitos para los que ha sido diseñado y brinde los servicios requeridos al usuario final. Porque por mucho que se identifiquen y resuelvan los defectos, el software se comportará perfectamente según las expectativas.

Primero comprendamos el ciclo de vida del defecto y luego pasaremos al flujo de trabajo y los diferentes estados del defecto.

Ciclo de vida del defecto –

En el proceso de desarrollo de software, el ciclo de vida del defecto es el ciclo de vida del defecto o error a partir del cual pasa cubriendo el conjunto específico de estados en toda su vida. Principalmente, el ciclo de vida del error se refiere a sus estados completos, desde que se detecta un nuevo defecto hasta que el probador lo cierra. Alternativamente, también se le llama Ciclo de vida del error.

El viaje del ciclo de defectos varía de una organización a otra y también de un proyecto a otro porque los procedimientos y plataformas de desarrollo, así como los métodos de prueba y las herramientas de prueba, difieren según las organizaciones y los proyectos. La cantidad de estados por los que pasa el defecto también varía según las diferentes herramientas utilizadas y el proceso seguido durante la prueba del software.

Flujo de trabajo del ciclo de vida de defectos/errores:

El siguiente diagrama ilustra el flujo de trabajo real del ciclo de vida del defecto.

El diagrama anterior muestra diferentes estados de defectos en el ciclo de vida de defectos y estos son los siguientes:

1. NUEVO –

Cuando el probador identifica cualquier defecto nuevo, cae en el estado ‘Nuevo’. Es el primer estado del ciclo de vida del insecto. El probador proporciona un documento de defecto adecuado al equipo de desarrollo para que el equipo de desarrollo pueda consultar el documento de defecto y corregir el error en consecuencia.

2. ASIGNADO –

Los defectos que están en el estado ‘Nuevo’ serán aprobados y ese defecto recién identificado se asigna al equipo de desarrollo para trabajar en el defecto y resolverlo. Cuando el defecto se asigna al equipo de desarrolladores, el estado del error cambia al estado ‘Asignado’.

3. ABIERTO –

En este estado ‘Abierto’, el equipo de desarrolladores está abordando el defecto y el equipo de desarrolladores trabaja en el defecto para corregir el error. En función de algún motivo específico, si el equipo de desarrolladores considera que el defecto no es apropiado, se transfiere al estado ‘Rechazado’ o ‘Diferido’.

4. FIJO –

Después de los cambios necesarios de códigos o después de corregir el error identificado, las marcas del equipo de desarrolladores indican que se ha solucionado.

5. PENDIENTE DE PRUEBA –

Durante la reparación del defecto, el equipo de desarrolladores pasa el nuevo código al equipo de prueba para que lo vuelva a probar. Y el código/aplicación está pendiente para volver a realizar la prueba en el lado del probador, por lo que el estado se asigna como ‘Pendiente de nueva prueba’.

6. VUELVA A PRUEBA –

En esta etapa, el probador comienza a trabajar para volver a probar el defecto para verificar si el desarrollador solucionó el defecto o no, y el estado se marca como ‘Reanudando’.

7. REABRIR –

Después de ‘Volver a probar’, si el equipo de prueba encontró que el error continúa como antes, incluso después de que el equipo de desarrolladores haya corregido el error, el estado del error cambia nuevamente a ‘Reabierto’. Una vez más, el error pasa al estado ‘Abierto’ y vuelve a pasar por el ciclo de vida. Esto significa que va a ser reparado por el equipo de desarrolladores.

8. VERIFICADO –

El probador vuelve a probar el error después de que el equipo de desarrollo lo corrigió y si el probador no encuentra ningún tipo de defecto/error, el error se corrige y el estado asignado es ‘Verificado’.

9. CERRADO –

Es el estado final del ciclo de defectos, después de que el equipo de desarrolladores corrigió el defecto cuando las pruebas encontraron que el error se resolvió y no persiste, luego marcan el defecto como un estado ‘Cerrado’.

Pocos estados más que también se incluyen en este ciclo de vida de defectos:

1. RECHAZADO –

Si el equipo de desarrolladores rechaza el defecto si consideran que el defecto no se considera un defecto genuino, y luego marcan el estado como ‘Rechazado’. La causa del rechazo puede ser cualquiera de estas tres, es decir, Defecto duplicado, NO un defecto, No reproducible.

2. DIFERIDO –

Todos los defectos tienen su impacto negativo en el software desarrollado y también tienen un nivel en función de su impacto en el software. Si el equipo de desarrolladores siente que el defecto identificado no es una prioridad principal y puede corregirse en futuras actualizaciones o lanzamientos, entonces el equipo de desarrolladores puede marcar el estado como ‘Diferido’. Significa que a partir del ciclo de vida del defecto actual se terminará.

3. DUPLICADO –

Algunas veces puede suceder que el defecto se repita dos veces o que el defecto sea el mismo que cualquier otro defecto, luego se marca como estado ‘Duplicado’ y luego el defecto es ‘Rechazado’.

4. NO ES UN DEFECTO –

Si el defecto no tiene impacto o efecto en otras funciones del software, entonces se marca como estado ‘NO ES UN DEFECTO’ y ‘Rechazado’.

5. NO REPRODUCIBLE –

Si el defecto no se reproduce debido a una discrepancia de plataforma, discrepancia de datos, discrepancia de compilación o cualquier otro motivo, el desarrollador marca el defecto como en un estado «No reproducible».

6. NO SE PUEDE ARREGLAR –

Si el equipo de desarrolladores no soluciona el defecto debido al soporte tecnológico, el costo de corregir el error es mayor, la falta de habilidad requerida o por cualquier otra razón, el equipo de desarrolladores marca el defecto como en el estado ‘No se puede arreglar’.

7. NECESITA MÁS INFORMACIÓN –

Este estado está muy cerca del estado ‘No reproducible’. Pero es diferente de eso. Cuando el equipo de desarrolladores no puede reproducir el defecto debido a que los pasos o el documento proporcionado por el evaluador son insuficientes o el documento de defectos no es tan claro para reproducir el defecto, el equipo de desarrolladores puede cambiar el estado a «Se necesita más información». Cuando el equipo de probadores proporciona un buen documento de defectos, el equipo de desarrolladores procede a corregir el error.

Ventajas de seguir un ciclo de vida de defectos:

• Entregar productos de alta calidad
• Mejore el retorno de la inversión (ROI) al reducir el costo del desarrollo
• Mejor comunicación, trabajo en equipo y conectividad
• Detecte problemas antes y comprenda las tendencias de defectos
• Mejor Servicio y Satisfacción del Cliente

Dificultades en el ciclo de vida del defecto:

• Variaciones del ciclo de vida de los insectos
• Sin control en el entorno de prueba