Menú

Seguimiento de errores del proyecto en vivo, métricas de prueba y aprobación de la prueba: capacitación gratuita de control de calidad, día 6

live project bug tracking

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Esta es la parte final de nuestro ' Capacitación en pruebas de software en un proyecto en vivo ”Serie.

Se tratará de defectos y también de algunos temas restantes que marcarán la finalización de la fase de ejecución de prueba del STLC.

En el Artículo anterior , mientras se realizaba la ejecución de la prueba, nos encontramos con una situación en la que no se cumplía el resultado esperado del caso de prueba. Además, identificamos algunos comportamientos inesperados durante las pruebas exploratorias.

Seguimiento de errores del proyecto en vivo, métricas de prueba y aprobación de la prueba

¿Qué sucede cuando nos encontramos con estas desviaciones?

Obviamente, tenemos que registrarlos y rastrearlos para asegurarnos de que estas desviaciones se manejen y finalmente se solucionen en el AUT.

#1) Estas desviaciones se conocen como defectos / errores / problemas / incidentes / errores / fallas.

#2) Todos los casos siguientes pueden registrarse como defectos

  • Requisitos faltantes
  • Requisitos de funcionamiento incorrecto
  • Requisitos extra
  • Incoherencias en los documentos de referencia
  • Problemas relacionados con el medio ambiente
  • Sugerencias de mejora

#3) El registro de defectos se realiza principalmente en hojas de Excel o mediante el uso de un software / herramienta de gestión de defectos. Para obtener información sobre cómo manejar los defectos a través de herramientas, intente usar los siguientes enlaces:

Lo que vas a aprender:

Cómo registrar los defectos de forma eficaz

Ahora intentaremos ver cómo registrar los defectos que encontramos en el artículo anterior en una hoja de Excel. Como siempre, es importante elegir un formato o plantilla estándar.

¿Qué es un buen servicio de correo electrónico?

Normalmente, las siguientes columnas forman parte del Informe de defectos:

  • ID de defecto: Para identificación única.
  • Descripción del defecto: Es como un título para describir brevemente el problema.
  • Módulo / sección de la AUT: Esto es opcional, solo para agregar más claridad en cuanto a indicar el área del AUT donde se encontró el problema.
  • Pasos para reproducir: ¿Cuál es la secuencia exacta de operaciones que se realizarán en el AUT para recrear el error? Además, si algún dato de entrada es específico del problema, esa información también debe introducirse.
  • Gravedad: Indicar la intensidad del problema y eventualmente el impacto que podría tener en el funcionamiento de la AUT. Las pautas sobre cómo asignar y qué valores asignar en este campo se pueden encontrar en el documento del plan de prueba. Por lo tanto, consulte la Documento del plan de prueba del artículo 3 .
  • Estado: Se discutirá más en el artículo.
  • Captura de pantalla: Una instantánea de la aplicación para mostrar el error cuando ocurrió.

Estos son algunos de los campos 'imprescindibles'. Esta plantilla se puede expandir (por ejemplo, para incluir el nombre del evaluador que informó el problema) o contratar ( Por ejemplo, el nombre del módulo eliminado) según sea necesario.

Siguiendo las pautas anteriores y utilizando la plantilla anterior, un ejemplo de registro / informe de defectos podría verse así:

Ejemplo de informe de defectos para el proyecto OrangeHRM Live:

Informe de defectos de OrangeHRM

=> Haga clic aquí para descargar el informe de defectos del proyecto en vivo

A continuación se muestra el informe de defectos de muestra creado en la herramienta qTest Test Management: (Haga clic en la imagen para ampliar)

Ejemplo de informe de defectos

Los defectos no son buenos cuando los registramos y los guardamos para nosotros. Tendremos que asignarlos en el orden correcto para que los equipos interesados ​​actúen sobre ellos. El proceso, a quién asignar o qué orden seguir, también se puede encontrar en el documento del plan de prueba. Es mayormente similar a (Haga clic en la imagen para ampliar)

Ciclo de defectos:

Ciclo de vida del defecto 1

A partir del proceso anterior, se puede observar que los errores pasan por diferentes personas y diferentes decisiones en el proceso de ser identificados para corregirlos. Para rastrear y establecer transparencia en cuanto al estado exacto en el que se encuentra un determinado error, se utiliza un campo de 'Estado' en el informe del error. Todo el proceso se conoce como 'ciclo de vida del error'. Para obtener más información sobre todos los estados y sus significados, consulte este Tutorial del ciclo de vida del error .

Algunos consejos para el seguimiento de errores

  • Cuando somos nuevos en un equipo / proyecto / AUT creativo, siempre es mejor discutir el problema que encontramos con un compañero para asegurarnos de que nuestra comprensión de lo que realmente causa un defecto sea correcta o no.
  • A proporcionar toda la información que es necesario para reproducir el problema. Un defecto que regresa a un equipo de pruebas con el estado establecido como 'No hay suficiente información' no se refleja de manera muy positiva en nosotros. Mira esta publicación - Cómo resolver todos los errores sin ninguna etiqueta de 'error no válido' .
  • Compruebe si surgió un problema similar antes de crear uno nuevo. Problemas 'duplicados' también son malas noticias para el equipo de control de calidad.
  • Si hay un problema, surge al azar y no sabemos los pasos / situaciones exactos en los que podemos recrear el problema; plantee el problema de todos modos. A riesgo de que el problema se establezca 'Irreproducible / no hay suficiente información' - todavía tenemos que asegurarnos de que manejamos todos los posibles fallos de funcionamiento en la mejor medida posible.
  • La practica general es que el equipo de QA crea los defectos de cada uno en una hoja de Excel durante un día y lo consolida al final del día.

El ciclo de vida completo del defecto

Para nuestro proyecto en vivo, si tuviéramos que seguir el ciclo de vida del defecto para el defecto 1,

reddit mejor VPN para torrenting
  • Cuando yo (el probador) lo creo, su estado es “Nuevo”. Cuando lo asigno al líder del equipo de control de calidad, el estado sigue siendo 'Nuevo', pero el propietario ahora es el líder de control de calidad.
  • El líder de control de calidad revisará el problema y, al determinar que es un problema válido, el problema se asignará al líder de desarrollo. En esta fase, el estado es “Asignado” y el propietario es el líder de desarrollo.
  • El líder de desarrollo asignará este problema a un desarrollador que trabajará para solucionarlo. El estado ahora será “Trabajo en progreso” (o algo similar a ese efecto), el propietario es el desarrollador.
  • Para el defecto 1, el desarrollador no puede reproducir el error, por lo que lo asigna de nuevo al equipo de control de calidad y establece el estado como “No puedo reproducir”.
  • Alternativamente, si el desarrollador pudo trabajar en él y solucionar un problema, el estado se establecería en “resuelto” y el problema se volvería a asignar al equipo de control de calidad.
  • El equipo de control de calidad lo recogerá, volverá a probar el problema y, si se soluciona, establecerá el estado en “Cerrado” . Si el problema persiste, el estado se establece en “Reabrir” y el proceso continúa.
  • Dependiendo de las otras situaciones, el estado se puede configurar como “Diferido” , 'No hay suficiente información', “Duplicar” , “trabajando según lo previsto” , etc.por el desarrollador.
  • Este método de registrar los defectos, informar y asignarlos, gestionarlos es una de las principales actividades realizadas por los miembros del equipo de QA durante la fase de ejecución de la prueba. Esto se hace a diario hasta que se completa un ciclo de prueba en particular.
  • Una vez finalizado el ciclo 1, el equipo de desarrollo tardará uno o dos días en consolidar todas las correcciones y reconstruir el código en la siguiente versión que se utilizará para el próximo ciclo.
  • El mismo proceso continúa nuevamente para el ciclo 2. Al final del ciclo, existe la posibilidad de que todavía haya algunos problemas 'Abiertos' o sin corregir en la aplicación.
  • En esta etapa, ¿seguimos con el ciclo 3? Si es así, ¿cuándo dejaremos de probar?

Criterios de salida para las pruebas del proyecto OrangeHRM Live

Aquí es donde empleamos lo que llamaríamos los 'Criterios de salida'. Esto está predefinido en el documento del plan de prueba. Es simplemente en la forma de la lista de verificación lo que determinará si concluimos la prueba después del ciclo 2 o vamos por un ciclo más. Parece que lo siguiente cuando se completa teniendo en cuenta algunas respuestas hipotéticas a las siguientes preguntas sobre el proyecto OrangeHRM:

Criterios de salida de prueba

Cuando miramos detenidamente la lista de verificación anterior, hay métricas y firmas mencionadas allí que no hemos discutido anteriormente. Hablemos de ellos ahora.

Métricas de prueba

Hemos establecido que durante la fase de ejecución de la prueba, los informes se envían a todos los demás miembros del equipo del proyecto para dar una idea clara sobre lo que está sucediendo en la fase de ejecución de QA . Esta información es importante para todos con el fin de obtener una validación sobre la calidad general del producto final.

Imagine que informo que se aprobaron 10 casos de prueba o se ejecutaron 100 casos de prueba; estos números son simplemente datos sin procesar y no brindan una muy buena perspectiva sobre cómo van las cosas.

Las métricas juegan un papel vital para llenar este vacío. Las métricas están en palabras simples, números inteligentes que el equipo de pruebas recopila y mantiene . Por ejemplo, si digo que el 90% de los casos de prueba pasaron, tiene más sentido que decir que se aprobaron 150 casos de prueba. ¿No es así?

Hay diferentes tipos de métricas recopiladas durante la fase de ejecución de la prueba. Qué métricas exactamente se deben recopilar y mantener durante qué períodos de tiempo; esta información se puede encontrar en el documento del plan de prueba.

Las siguientes son las métricas de prueba recopiladas con más frecuencia para la mayoría de los proyectos:

  • Pasa el porcentaje de los casos de prueba
  • Densidad de defectos
  • Porcentaje de defectos críticos
  • Defectos, número sabio de gravedad

Revisar la Informe de estado adjunto a este artículo para ver cómo se utilizan estas métricas.

Informe de finalización / cierre de la prueba

Como tenemos que notificar a todas las partes interesadas que las pruebas han comenzado, también es el deber del equipo de control de calidad informar a todos que las pruebas se han completado y compartir los resultados. Por lo tanto, normalmente se envía un correo electrónico desde el equipo de control de calidad (generalmente el líder del equipo / gerente de control de calidad) dando una indicación de que el equipo de control de calidad ha firmado el producto adjuntando los resultados de la prueba y la lista de problemas abiertos / conocidos.

Ejemplo de correo electrónico de aprobación de prueba:

A: Cliente, PM, equipo de desarrollo, equipo de base de datos, BA, equipo de control de calidad, equipo de medio ambiente (y cualquier otra persona que deba incluirse)
Email: Hola equipo,

El equipo de QA aprueba el software OrangeHRM versión 3.0 después de completar con éxito los 2 ciclos de pruebas funcionales del sitio web.

Los casos de prueba y sus resultados de ejecución se adjuntan al correo electrónico. (O mencione la ubicación donde están presentes. O si utiliza un software de gestión de pruebas, proporcione detalles sobre el mismo).

La lista de problemas conocidos también se adjunta al correo electrónico. (Nuevamente, se pueden agregar otras referencias que tengan sentido).

Gracias,
Líder del equipo de control de calidad.

Archivos adjuntos: Informe de ejecución final, informe final de problemas / defectos, lista de problemas conocidos

Una vez que el equipo de control de calidad envía el correo electrónico de aprobación de la prueba, terminamos oficialmente con el proceso de STLC. Esto no necesariamente marca la finalización de la fase de 'Prueba' del SDLC. Todavía tenemos que terminar las pruebas de UAT para que eso suceda. Encontrar más detalles sobre las pruebas UAT aquí .

Una vez finalizado el UAT, el SDLC pasa a la fase de implementación en la que se activa y está disponible para que sus clientes / usuarios finales lo consuman.

¡Eso es!

Este ha sido nuestro esfuerzo para llevar la experiencia más viva como QA Project a nuestros lectores. Háganos saber sus comentarios y preguntas sobre esta serie de capacitación gratuita en línea sobre control de calidad de pruebas de software.

Lectura recomendada

^