defect management process
Introducción al proceso de gestión de defectos:
El proceso y las pruebas más enfocados permitirán menos software con errores en el mercado.
Prevención de defectos es mucho más eficiente y eficaz para reducir el número de defectos y también es muy rentable para corregir los defectos encontrados durante la etapa inicial del proceso de software. La mayoría de las organizaciones realizan Descubrimiento de defectos , Eliminación de defectos y luego La mejora de procesos que se conoce colectivamente como Proceso de gestión de defectos .
prueba unitaria vs ejemplo de prueba de integración
Lo que vas a aprender:
- Objetivos del proceso de gestión de defectos (DMP)
- Ciclo de vida de la gestión de defectos
- Proceso de gestión de defectos
- Conclusión
- Lectura recomendada
Objetivos del proceso de gestión de defectos (DMP)
A continuación se presentan los diversos objetivos de este proceso:
- Prevenir el defecto
- Detección temprana
- Minimiza el impacto
- Resolución del defecto
- La mejora de procesos
Antes de explorar el proceso de gestión de defectos, primero comprendamos ¿Qué es realmente un defecto o error?
Ciclo de vida de la gestión de defectos
Cuando un sistema proporciona un resultado diferente al del requisito comercial real, es decir, cuando hay una desviación del requisito comercial real u original, podemos decir que hay un defecto en el sistema / software.
Cuando el equipo de prueba ejecuta los casos de prueba, se encuentra con una situación en la que el resultado real de la prueba es diferente del resultado esperado. Esta variación se denomina Defecto .
Básicamente, un defecto de software es una condición que no cumple con los requisitos del software. El defecto es un error o falla que produce un comportamiento inesperado o incorrecto en el sistema.
Para manejar los proyectos de manera adecuada, necesita saber cómo lidiar con el desarrollo y la liberación, pero junto con eso también necesita saber cómo manejar los defectos.
Imagínense, ¿qué pasará si el equipo de pruebas informa los defectos verbalmente y el equipo de desarrollo también actualiza verbalmente el estado del defecto? El proceso será más complicado ya que estos defectos incluyen todos los defectos como realmente arreglado y funcionando como se esperaba, arreglado pero aún no funciona, rechazado, pospuesto y el proceso continúa.
En el caso anterior, a medida que aumenta el número de defectos y la comunicación se realiza verbalmente, la situación pronto será peor. Para controlar y manejar el defecto de manera efectiva, necesita un ciclo de vida del defecto adecuado.
El ciclo de vida de los defectos asegura que el proceso sea uniforme y estandarizado. Un defecto alcanza diferentes estados en el ciclo de vida. Una vez que se ha encontrado un defecto, pasa por varias etapas durante su vida y se conoce comúnmente como Ciclo de vida del defecto .
Por lo general, el ciclo de vida del defecto comienza desde la etapa en que el equipo de pruebas detecta o plantea el defecto y finaliza cuando se cierra un defecto, ya sea asegurándose de que no sea reproducible o rechazado por un equipo de desarrollo. El número de estados por los que pasa un defecto varía de un proyecto a otro.
Otras lecturas:
Nota: El ciclo inferior difiere ligeramente de una organización a otra.
El ciclo de vida de defectos a continuación cubre todos los estados posibles:
- Siempre que el equipo de pruebas encuentra un defecto en la aplicación, lo plantean con el estado ' NUEVO ”.
- Cuando un líder de control de calidad revisa un nuevo defecto y si el defecto es válido, el estado del defecto sería ' Abierto ”Y está listo para ser asignado al equipo de desarrollo.
- Cuando un líder de control de calidad asigna el defecto al desarrollador correspondiente, el estado del defecto se marcaría como ' Asignado ”. Un desarrollador debe comenzar a analizar y corregir el defecto en esta etapa.
- Cuando el desarrollador siente que el defecto no es genuino o válido, entonces el desarrollador rechaza el defecto. El estado del defecto se marca como ' Rechazado ”Y asignado de nuevo al equipo de pruebas.
- Si el defecto registrado se repite dos veces o ambos defectos informados tienen resultados y pasos similares para reproducir, entonces el estado de un defecto se cambia a ' Duplicar ”.
- Si hay algunos problemas o obstáculos en la versión actual para corregir un defecto en particular, entonces el defecto se tomará en las próximas versiones en lugar de en la versión actual y luego se marcará como ' Diferido ' o ' Aplazado ”.
- Cuando un desarrollador no puede reproducir el defecto mediante los pasos mencionados en 'Pasos para reproducir' por el equipo de pruebas, entonces el desarrollador puede marcar el defecto como ' No reproducible' . En esta etapa, el equipo de pruebas debe proporcionar pasos de reproducción detallados a un desarrollador.
- Si el desarrollador no tiene claros los pasos para reproducir proporcionados por un control de calidad para reproducir el defecto, entonces puede marcarlo como ' Necesitas más información ”. En este caso, el equipo de pruebas debe proporcionar los detalles necesarios al equipo de desarrollo.
- Si ya se conoce un defecto y está presente en el entorno de producción, el defecto se marca como ' Defecto conocido ”.
- Cuando un desarrollador realiza los cambios necesarios, el defecto se marca como ' Reparado ”.
- El desarrollador ahora pasa el defecto al equipo de pruebas para que lo verifique, por lo que el desarrollador cambia el estado a ' Listo para volver a probar ”.
- Si el defecto no tiene más problemas y se verifica correctamente, el evaluador marca el defecto como ' Cerrado ”.
- Al volver a probar el defecto, si el probador encontró que el defecto aún es reproducible o parcialmente reparado, el defecto se marcaría como ' Reabierto ”. Ahora el desarrollador tiene que volver a examinar este defecto.
Un ciclo de vida de defectos bien planificado y controlado proporciona el número total de defectos encontrados en una versión o en todas las versiones. Este proceso estandarizado brinda una imagen clara de cómo se escribió el código, qué tan correctamente se han realizado las pruebas, cómo se ha liberado el defecto o el software, etc. Esto reducirá la cantidad de defectos en la producción al encontrar los defectos en las pruebas. fase en sí.
Proceso de gestión de defectos
El proceso de gestión de defectos se explica a continuación en detalle.
# 1) Prevención de defectos:
Prevención de defectos es el mejor método para eliminar los defectos en la etapa inicial de la prueba en lugar de encontrar los defectos en la etapa posterior y luego arreglarlos. Este método también es rentable ya que el costo requerido para reparar los defectos encontrados en las primeras etapas de la prueba es muy bajo.
Sin embargo, no es posible eliminar todos los defectos, pero al menos puede minimizar el impacto del defecto y el costo de repararlo.
Los principales pasos involucrados en la prevención de defectos son los siguientes:
- Identificar el riesgo crítico : Identifique los riesgos críticos en el sistema que impactarán más si ocurrieron durante la prueba o en la etapa posterior.
- Estimar el impacto esperado : Para cada riesgo crítico, calcule cuál sería el impacto financiero si el riesgo se encontrara realmente.
- Minimizar el impacto esperado : Una vez que haya identificado todos los riesgos críticos, tome los riesgos más altos que pueden ser dañinos para el sistema si se encuentran e intente minimizar o eliminar el riesgo. Para los riesgos que no se pueden eliminar, reduce la probabilidad de ocurrencia y su impacto financiero.
# 2) Línea de base de entregables:
Cuando un entregable (sistema, producto o documento) alcanza su hito predefinido, se puede decir que un entregable es una línea de base. En este proceso, el producto o el entregable se mueve de una etapa a otra y, a medida que el entregable se mueve de una etapa a otra, los defectos existentes en el sistema también se trasladan al siguiente hito o etapa.
Es soporte técnico preguntas y respuestas de la entrevista
Por ejemplo, considere un escenario de codificación, prueba unitaria y luego prueba del sistema. Si un desarrollador realiza la codificación y las pruebas unitarias, el equipo de pruebas realiza las pruebas del sistema. Aquí, la codificación y las pruebas unitarias son un hito y las pruebas del sistema son otro hito.
Por lo tanto, durante las pruebas unitarias, si el desarrollador encuentra algunos problemas, no se considera un defecto, ya que estos problemas se identifican antes de que se cumpla la fecha límite del hito. Una vez que se han completado la codificación y la prueba unitaria, el desarrollador entrega el código para la prueba del sistema y luego puede decir que el código es 'Línea de base' y listo para el próximo hito, aquí, en este caso, se trata de 'pruebas del sistema'.
Ahora, si los problemas se identifican durante la prueba, se denomina defecto, ya que se identifica después de la finalización del hito anterior, es decir, la codificación y la prueba unitaria.
Básicamente, los entregables se establecen como base cuando se finalizan los cambios en los entregables y se identifican y corrigen todos los posibles defectos. Luego, el mismo entregable pasa al siguiente grupo que trabajará en él.
# 3) Descubrimiento de defectos:
Es casi imposible eliminar todos los defectos del sistema y hacer un sistema libre de defectos. Pero puede identificar los defectos antes de que se vuelvan más costosos para el proyecto. Podemos decir que el defecto descubierto significa que se llama formalmente a la atención del equipo de desarrollo y, después de analizarlo, el equipo de desarrollo del defecto también lo aceptó como defecto.
Los pasos involucrados en el descubrimiento de defectos son los siguientes:
- Encuentra un defecto : Identifique los defectos antes de que se conviertan en un problema importante para el sistema.
- Informar defecto : Tan pronto como el equipo de pruebas encuentra un defecto, su responsabilidad es informar al equipo de desarrollo de que hay un problema identificado que debe analizarse y solucionarse.
- Reconocer defecto : Una vez que el equipo de pruebas asigna el defecto al equipo de desarrollo, es responsabilidad del equipo de desarrollo reconocer el defecto y continuar solucionándolo si es un defecto válido.
# 4) Resolución de defectos:
En el proceso anterior, el equipo de pruebas ha identificado el defecto y lo ha informado al equipo de desarrollo. Ahora aquí el equipo de desarrollo debe proceder para la resolución del defecto.
Los pasos involucrados en la resolución de defectos son los siguientes:
- Prioriza el riesgo : El equipo de desarrollo analiza el defecto y prioriza la reparación del defecto. Si un defecto tiene más impacto en el sistema, entonces la reparación del defecto tiene una alta prioridad.
- Arreglar el defecto : Según la prioridad, el equipo de desarrollo corrige el defecto, los defectos de mayor prioridad se resuelven primero y los de menor prioridad se corrigen al final.
- Informar la resolución : Es responsabilidad del equipo de desarrollo asegurarse de que el equipo de pruebas sepa cuándo se van a arreglar los defectos y cómo se ha solucionado, es decir, cambiando uno de los archivos de configuración o realizando algunos cambios en el código. Esto será útil para que el equipo de pruebas comprenda la causa del defecto.
# 5) Mejora de procesos:
Aunque en el proceso de resolución de defectos, los defectos se priorizan y corrigen, desde la perspectiva del proceso, no significa que los defectos de menor prioridad no sean importantes y no afecten mucho al sistema. Desde el punto de vista de la mejora del proceso, todos los defectos identificados son los mismos que los defectos críticos.
Incluso estos defectos menores brindan la oportunidad de aprender cómo mejorar el proceso y prevenir la aparición de cualquier defecto que pueda afectar la falla del sistema en el futuro. La identificación de un defecto que tenga un impacto menor en el sistema puede no ser un gran problema, pero la aparición de dicho defecto en el sistema sí lo es.
Para mejorar el proceso, todos en el proyecto deben mirar hacia atrás y verificar dónde se originó el defecto. En base a eso, puede realizar cambios en el proceso de validación, el documento de base, el proceso de revisión que pueden detectar los defectos al principio del proceso que son menos costosos.
Conclusión
El proceso de gestión de defectos debe seguirse durante todo el proceso de desarrollo de software y no solo para actividades específicas de prueba o desarrollo.
Si se encuentra un defecto en la fase de prueba, entonces se puede plantear la pregunta de que si el defecto se detecta en esta fase, ¿qué pasa con los otros defectos que están vivos en el sistema que pueden causar una falla del sistema si ocurre y aún no se descubre?
Por lo tanto, todos los procesos, como el proceso de revisión, las pruebas estáticas, la inspección, etc., deben fortalecerse y todos en el proyecto deben tomarse en serio el proceso y contribuir donde sea necesario. La alta dirección de la organización también debería comprender y apoyar el proceso de gestión de defectos.
Los enfoques de prueba, el proceso de revisión, etc., deben elegir en función del objetivo del proyecto o del proceso organizativo.
Espero que este artículo informativo sobre el proceso de gestión de defectos sea de gran ayuda para usted.
Lectura recomendada
- ¿Qué es la técnica de prueba basada en defectos?
- Proceso de clasificación de defectos y formas de manejar Reunión de clasificación de defectos
- ¿Qué es el ciclo de vida de defectos / errores en las pruebas de software? Tutorial del ciclo de vida de los defectos
- Tutorial de Bugzilla: Tutorial práctico de la herramienta de gestión de defectos
- Métodos y técnicas de prevención de defectos
- Tutorial de la herramienta de gestión de defectos de IBM Rational Team Concert
- Cómo reproducir un defecto no reproducible y hacer que el esfuerzo de prueba valga la pena
- Las pruebas de software tienen que ver con las ideas (y cómo generarlas)