¿Qué es Bug?
Un error es la consecuencia / resultado de un error de codificación.
Defecto en las pruebas de software
Un defecto en las pruebas de software es una variación o desviación de la aplicación de software de los requisitos del usuario final o los requisitos comerciales originales. Un defecto de software es un error en la codificación que provoca resultados incorrectos o inesperados de un programa de software que no cumple con los requisitos reales. Los probadores pueden encontrar tales defectos al ejecutar los casos de prueba.
Estos dos términos tienen una línea de diferencia muy fina. En la industria, ambos son fallas que deben corregirse y, por lo tanto, algunos de los equipos de prueba los utilizan de manera intercambiable.
Cuando los evaluadores ejecutan los casos de prueba, es posible que se encuentren con resultados de prueba que sean contradictorios con los resultados esperados. Esta variación en los resultados de las pruebas se denomina Defecto de software. Estos defectos o variaciones se denominan con diferentes nombres en diferentes organizaciones, como problemas, errores o incidentes.
En este tutorial, aprenderá:
- Informe de error
- Proceso de gestión de defectos
- Descubrimiento
- Categorización
- Resolución
- Verificación
- Cierre
- Reportando
- Métricas de defectos importantes
Informe de error en las pruebas de software
Un informe de errores en las pruebas de software es un documento detallado sobre los errores encontrados en la aplicación de software. El informe de errores contiene todos los detalles sobre los errores, como la descripción, la fecha en que se encontró el 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.
Mientras informa el error al desarrollador, su Informe de error debe contener la siguiente información
- Defect_ID : número de identificación único del defecto.
- Descripción del defecto: descripción detallada del defecto, incluida información sobre el módulo en el que se encontró el defecto.
- Versión : versión de la aplicación en la que se encontró el defecto.
- Pasos : pasos detallados junto con capturas de pantalla con las que el desarrollador puede reproducir los defectos.
- Fecha de aparición : fecha en la que se produce el defecto
- Referencia : en qué lugar proporcione una referencia a los documentos como. requisitos, diseño, arquitectura o incluso capturas de pantalla del error para ayudar a comprender el defecto
- Detectado por : nombre / ID del probador que planteó el defecto
- Estado : estado del defecto, más sobre esto más adelante
- Corregido por : nombre / ID del desarrollador que lo arregló
- Fecha de cierre : fecha en la que se cierra el defecto.
- Severidad que describe el impacto del defecto en la aplicación.
- Prioridad relacionada con la urgencia de solucionar los defectos. La prioridad de gravedad podría ser alta / media / baja en función de la urgencia del impacto en la que se debe corregir el defecto, respectivamente.
Haga clic aquí si el video no es accesible
Recursos
Descargue una plantilla de informe de defectos de muestra
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:
En la próxima semana, el evaluador responde
Como en el caso anterior, si el defecto de comunicación se hace de forma verbal, pronto las cosas se complican mucho. Para controlar y gestionar los errores de forma eficaz, necesita un ciclo de vida de defectos.
¿Qué es el proceso de gestión de defectos?
La gestión de defectos es un proceso sistemático para identificar y corregir errores. Un ciclo de gestión de defectos contiene las siguientes etapas: 1) Descubrimiento del defecto, 2) Categorización del defecto 3) Reparación del defecto por los desarrolladores 4) Verificación por los probadores, 5) Cierre del defecto 6) Informes de defectos al final del proyecto
Este tema lo guiará sobre cómo aplicar el proceso de gestión de defectos en el sitio web del proyecto Guru99 Bank. Puede seguir los pasos a continuación para gestionar los defectos.
Descubrimiento
En la fase de descubrimiento, los equipos del proyecto deben descubrir tantos defectos como sea posible, antes de que el cliente final pueda descubrirlos. Se dice que un defecto se descubre y cambia a estado aceptado cuando es reconocido y aceptado por los desarrolladores
En el escenario anterior, los probadores descubrieron 84 defectos en el sitio web Guru99.
Echemos un vistazo al siguiente escenario; su equipo de pruebas descubrió algunos problemas en el sitio web de Guru99 Bank. Los consideran defectos y los informan al equipo de desarrollo, pero hay un conflicto:
En tal caso, como administrador de pruebas, ¿qué hará?
A) De acuerdo con el equipo de prueba en que es un defecto.
B) Test Manager asume el papel de juez para decidir si el problema es un defecto o no
C) Acordar con el equipo de desarrollo que no es un defecto Corregir InCorrecto
En tal caso, se debe aplicar un proceso de resolución para resolver el conflicto, usted asume el papel de juez para decidir si el problema del sitio web es un defecto o no.
Categorización
La categorización de defectos ayuda a los desarrolladores de software a priorizar sus tareas. Eso significa que este tipo de prioridad ayuda a los desarrolladores a corregir primero los defectos que son muy cruciales.
Los defectos suelen ser categorizados por Test Manager:
Hagamos un pequeño ejercicio como sigue Arrastrar y soltar la prioridad de defecto a continuación
- Crítico
- Alto
- Medio
- Bajo
| 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 dispositivos móviles |
|
| 4) El sitio web no pudo recordar la sesión de inicio de sesión del usuario |
|
| 5) Algunos enlaces no funcionan |
|
Aquí están las respuestas recomendadas
| No. | Descripción | Prioridad | Explicación |
|---|---|---|---|
| 1 | El rendimiento del sitio web es demasiado lento | Alto | 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, se trata de errores graves |
| 3 | La GUI del sitio web no se muestra correctamente en dispositivos móviles | Medio | El defecto afecta al usuario que utiliza Smartphone para visualizar el sitio web. |
| 4 | El sitio web no pudo recordar la sesión de inicio de sesión del usuario | Alto | Este es un problema grave, ya que el usuario podrá iniciar sesión pero no podrá realizar más transacciones. |
| 5 | Algunos enlaces no funcionan | Bajo | Esta es una solución fácil para los desarrolladores y el usuario aún puede acceder al sitio sin estos enlaces. |
Resolución de defectos
La resolución de defectos en las pruebas de software es un proceso paso a paso para corregir los defectos. El proceso de resolución de defectos comienza con la asignación de defectos a los desarrolladores, luego los desarrolladores programan el defecto para que se solucione según la prioridad, luego se corrigen los defectos y finalmente los desarrolladores envían un informe de resolución al administrador de pruebas. Este proceso ayuda a corregir y rastrear defectos fácilmente.
Puede seguir los siguientes pasos para corregir el defecto.
- Asignación : asignada a un desarrollador u otro técnico para que la corrija, y cambió el estado a Respondiendo .
- Fijación de horarios : el lado del desarrollador se hace cargo de esta fase. Ellos crearán un cronograma para corregir estos defectos, dependiendo de la prioridad del defecto.
- Solucione el defecto : mientras el equipo de desarrollo está arreglando los defectos, el Administrador de pruebas rastrea el proceso de reparación de defectos en comparación con el programa anterior.
- Informe de la resolución : obtenga un informe de la resolución de los desarrolladores cuando se solucionen los defectos.
Verificación
Una vez que el equipo de desarrollo solucionó y notificó el defecto, el equipo de pruebas verifica que los defectos se hayan resuelto realmente.
Por ejemplo, en el escenario anterior, cuando el equipo de desarrollo informó que ya arreglaron 61 defectos, su equipo volvería a probar para verificar que estos defectos realmente se corrigieron o no.
Cierre
Una vez que se ha resuelto y verificado un defecto, el defecto cambia de estado como cerrado . Si no es así, ha enviado un aviso al desarrollo para que vuelva a comprobar el defecto.
Notificación de defectos
El informe de defectos en las pruebas de software es un proceso en el que los administradores de pruebas preparan y envían el informe de defectos al equipo de gestión para recibir comentarios sobre el proceso de gestión de defectos y el estado de los defectos. Luego, el equipo de administración verifica el informe de defectos y envía comentarios o brinda más apoyo si es necesario. Los informes de defectos ayudan a comunicar, rastrear y explicar mejor los defectos en detalle.
El consejo de administración tiene derecho a conocer el estado del defecto. Deben comprender el proceso de gestión de defectos para apoyarlo en este proyecto. Por lo tanto, debe informarles sobre la situación actual del defecto para recibir comentarios de ellos.
Métricas de defectos importantes
Respalde el escenario 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 la prueba?
Esta es una pregunta que todo administrador de pruebas quiere saber. Hay 2 parámetros que puede considerar de la siguiente manera
En el escenario anterior, puede calcular que la tasa de rechazo de deserción (DRR) es 20/84 = 0.238 (23.8%).
Otro ejemplo, se supone que el sitio web de Guru99 Bank tiene un total de 64 defectos, pero su equipo de pruebas solo detectó 44 defectos, es decir, no detectaron 20 defectos. Por lo tanto, puede calcular que la tasa de fuga por defecto (DLR) es 20/64 = 0,312 (31,2%).
Conclusión, la calidad de la ejecución de la prueba se evalúa mediante los siguientes dos parámetros
Cuanto menor sea el valor de DRR y DLR, mejor será la calidad de ejecución de la prueba. ¿Cuál es el rango de relación que es aceptable ? Este rango podría definirse y aceptarse en base al objetivo del proyecto o puede referirse a las métricas de proyectos similares.
En este proyecto, el valor recomendado de proporción aceptable es 5 ~ 10%. Significa que la calidad de la ejecución de la prueba es baja. Debe encontrar una contramedida para reducir estas proporciones, como
- Mejore las habilidades de prueba del miembro.
- Dedique más tiempo a la ejecución de la prueba, especialmente a revisar los resultados de la ejecución de la prueba.