Saltar al contenido

Proceso de gestión de defectos en las pruebas de software (plantilla de informe de errores)

¿Qué es un error?

Un error es la consecuencia / resultado de un error de codificación.

Defectuoso en las pruebas de software

UNA. Defectuoso en las pruebas de software es un cambio o desviación de la aplicación de software de las necesidades del usuario final o los requisitos comerciales básicos. Un error de codificación es un defecto de software que produce resultados incorrectos o inesperados de un programa de software que no cumple con los requisitos reales. Los probadores pueden experimentar tales defectos al realizar los casos de prueba.

Estos dos términos tienen una línea de diferencia muy fina. En la industria, ambos son defectos que deben corregirse y, por lo tanto, son intercambiables que algunos de los Prueba equipos.

Cuando los probadores realizan los casos de prueba, pueden encontrar resultados de prueba que sean contrarios a los resultados esperados. Esta variación en los resultados de las pruebas se denomina Deficiencia de software. Diferentes nombres en diferentes organizaciones se refieren a estos defectos o variaciones como problemas, errores o incidentes.

En este tutorial, aprenderá:

Informe de error en las pruebas de software

UNA. Informe de error en las pruebas de software Es un documento detallado sobre los errores encontrados en la aplicación de software. Un informe de error incluye todos los detalles de un error, como un informe, la fecha en que se encontró un error, el nombre del probador que lo encontró, el nombre del desarrollador que lo solucionó, etc. El informe de errores ayuda a identificar errores similares en el futuro para que puedan evitarse.

Al informar del error al desarrollador, su Informe de error debe contener la siguiente información

Hacer clic aquí si el video no es accesible

Recursos

Descargar modelo de muestra de informes defectuosos

Considere lo siguiente como administrador de pruebas

Su equipo encontró errores mientras probaba el proyecto Guru99 Banking.

Después de una semana, el desarrollador responde:

La próxima semana, el probador responderá

Como en el caso anterior, si la comunicación se hace de boca en boca, las cosas pronto se complicarán mucho. Para controlar y gestionar los fallos de forma eficaz, necesita un ciclo de vida de fallos.

¿Qué es el proceso de gestión del déficit?

La gestión de déficit es un proceso sistemático para identificar y corregir fallos. Los siguientes pasos se encuentran en el ciclo de gestión de fallas 1) Descubrimiento Descubrimiento, 2) Categorización de defectos 3) Reparadores de reparaciones 4) Verificación del probador, 5) Cierre defectuoso 6) Informes de fin de proyecto defectuosos

Este tema lo guiará sobre cómo implementar el proceso de gestión de fallas en el sitio web del proyecto Guru99 Bank. Puede seguir los pasos a continuación para administrar fallas.

Descubrimientos

En la fase de descubrimiento, los equipos del proyecto deben averiguar cómo suficiente defectos como lata, antes de que el cliente final pueda averiguarlo. Se dice que se ha encontrado una falla y cambia a estado aceptado cuando sea reconocido y aceptado por los desarrolladores

En el caso anterior, los probadores encontraron 84 fallas en el sitio web de Guru99.

Necesitamos mirar el siguiente escenario; su equipo de prueba encontró una serie de problemas en el sitio web de Guru99 Bank. Los consideran fallas y se informan al equipo de desarrollo, pero hay un conflicto:

En ese caso, como administrador de pruebas, ¿qué harás?

Derecha

Equivocado

En ese caso, se debe implementar un proceso de resolución para resolver el conflicto, usted asume el papel de juez para decidir si el problema del sitio web es culpable o no.

Categorización

La categorización defectuosa ayuda a los desarrolladores de software a priorizar sus tareas. Esto significa que tal prioridad ayuda a los desarrolladores a corregir esas fallas primero, lo cual es crucial.

Los defectos suelen ser categorizados por Test Manager:

Hagamos un pequeño ejercicio de la siguiente manera Arrastre y suelte la prioridad defectuosa a continuación

1) El rendimiento del sitio web es demasiado lento
2) La función de inicio de sesión del sitio web no funciona correctamente
3) La GUI del sitio web no se muestra correctamente en Móvil Gairis
4) Es posible que el sitio web no recuerde la sesión de inicio de sesión del usuario.
5) Algunas conexiones no funcionan

Aquí están las respuestas sugeridas

No. Suelte Prioridad Explicación
1 El rendimiento del sitio web es demasiado lento Elevado El error de rendimiento puede causar grandes inconvenientes al usuario.
2 La función de inicio de sesión del sitio web no funciona correctamente Crítico El inicio de sesión es una de las funciones principales del sitio web bancario si esta función no funciona, es un error grave
3 La GUI del sitio web no se muestra correctamente en dispositivos móviles Medio La avería afecta al usuario que utiliza un Smartphone para visualizar el sitio web.
4 Es posible que el sitio web no recuerde la sesión de inicio de sesión del usuario Elevado Este es un problema grave ya que el usuario podrá iniciar sesión pero no podrá realizar ninguna transacción adicional.
5 Algunas conexiones no funcionan Bajo Esta es una configuración fácil para los desarrolladores y el usuario puede acceder al sitio sin estos enlaces.

Resolución defectuosa

Resolución defectuosa La prueba de software para corregir las fallas es un proceso paso a paso. El proceso de resolución de fallas comienza con la asignación de fallas a los desarrolladores, luego los desarrolladores corrigen la falla de acuerdo con la prioridad, luego corrigen las fallas y finalmente los desarrolladores envían un informe de reparación al administrador de pruebas. Este proceso ayuda a reparar y rastrear fácilmente las fallas.

Puede seguir estos pasos para solucionar el problema.

Verificación

Después del equipo de desarrollo reparado y informó la culpa, el equipo de prueba verifica que las fallas están realmente resueltas.

Por ejemplo, en el caso anterior, cuando el equipo de desarrollo informó que ya había solucionado 61 defectos, su equipo volvería a probar para verificar que esos defectos se corrigieron o no.

Cerrado

Una vez que se resuelve y verifica una falla, la falla se cambia a cerrado. Si no es así, ha enviado una notificación al desarrollo para que vuelva a comprobar la avería.

Informes defectuosos

Informes defectuosos La prueba de software es un proceso en el que los gerentes de prueba preparan y envían el informe de defectos al equipo de administración para recibir comentarios sobre el proceso de administración de fallas y el estado de las fallas. Luego, el equipo de administración verifica el informe de defectos y envía comentarios o brinda soporte adicional si es necesario. Los informes de defectos ayudan a identificar, rastrear y explicar mejor los defectos.

El consejo de administración se reserva el derecho a conocer el estado de los defectos. Necesitan comprender el proceso de gestión de fallas para respaldarlo en este proyecto. Por lo tanto, debe informarles de la situación actual de la falla para recibir comentarios de ellos.

Métricas clave defectuosas

Volviendo al caso anterior. El desarrollador y los equipos de prueba han revisado los defectos informados. Aquí está el resultado de esa discusión

¿Cómo medir y evaluar la calidad de la ejecución de las pruebas?

Esta es una pregunta que todos los administradores de pruebas deben conocer. Hay 2 parámetros que puede considerar de la siguiente manera

En el caso anterior, puede tasa de rechazo de fallas (RRD) que 20/84 = 0,238 (23,8%).

Otro ejemplo, supuestamente completo en el sitio web de Guru99 Bank 64 fallas, pero su equipo de prueba solo detecta 44 defectos, es decir, perdieron 20 defectos. Por lo tanto, puede calcular que la tasa de fuga de fallas (DLR) es 20/64 = 0.312 (31,2%).

Conclusión, la calidad de la ejecución de la prueba se evalúa siguiendo dos parámetros

Cuanto menor sea el valor de DRR y DLR, mejor será el estándar de prueba. ¿Cuál es el rango de relación? aceptable? Este rango podría definirse y aceptarse como base en el objetivo del proyecto o podría transmitir métricas similares del proyecto.

En este proyecto, el valor recomendado es la proporción aceptable 5 ~ 10%. Significa que la calidad de la ejecución de la prueba es baja. Debería encontrar una resistencia a estas proporciones como