Tabla de contenidos
¿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
- Defect_ID – Número de identificación único de la avería.
- Descripción defectuosa – Descripción detallada del defecto, incluida información sobre el módulo donde se encontró el defecto.
- Versión – Versión defectuosa de la aplicación.
- Grados – Pasos detallados así como capturas de pantalla donde el desarrollador puede reproducir los defectos.
- Fecha de aumento – Fecha en que se levantará la falta
- Referencia– dónde se encuentra Consulte los documentos como. necesidades, diseño, arquitectura o incluso capturas de pantalla del error para ayudar a comprender la falla
- Detectada por – Nombre / Identidad del probador que planteó la falla
- Estado – Estado de falla, más sobre esto más adelante
- Arreglado por – Nombre / Identidad del desarrollador que lo arregló
- Fecha de cierre – Fecha en que se cerrará la avería
- Intensidad que describe el impacto de la falla en la aplicación
- Prioridad Relacionando la urgencia para arreglar defectos. La prioridad de gravedad puede ser alta / media / baja en función de la urgencia del impacto en caso de que se solucione la falla, respectivamente.
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:
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.
- Tarea: Asignado a otro desarrollador o técnico para establecer y cambiar el estado a Respondiendo.
- Configuración de horario: El lado del desarrollador está a la cabeza en esta fase. Crearán un cronograma para arreglar estas fallas, dependiendo de la prioridad de las fallas.
- Arreglar la falla: Mientras el equipo arregla las fallas, Test Manager rastrea el proceso de reparación de fallas en comparación con el programa anterior.
- Informar la resolución: Obtenga un informe secreto de los desarrolladores cuando se corrijan los errores.
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
- Excelencia habilidades de prueba del miembro.
- Toma más tiempo para probar la ejecución, en particular para revisar los resultados de ejecución de la prueba.