Cómo redactar buenos informes de errores: recomendaciones

Imagina que eres un desarrollador y un evaluador te trae un error que se encontró durante la regresión. Quieres solucionar este error, por lo que solicitas que se cree un ticket. Ya estás imaginando cómo lo detectarás, vincularás las solicitudes de incorporación de cambios y agregarás estimaciones para que el gerente de producto no tenga preguntas.

Pasa un tiempo y aparece un nuevo ticket, pero en su interior solo hay un par de líneas y una captura de pantalla. Con un suspiro, intentas reproducir el error con esta información, pero no hay ningún error. Lo intentas varias veces, pero al final le escribes al tester que el error no se puede reproducir y comienza una nueva ronda de aclaraciones.

Estás gastando tiempo que podría haberse utilizado para trabajar en nuevas tareas, corregir otros errores o incluso ver anime refactorizando el código.

Mi nombre es Evgeny Domnin , soy un QA y trataré de compartir mi opinión sobre qué hace que un informe de error sea bueno. Perdón por la introducción tan larga, comencemos.

Título

Intente responder tres preguntas en el título del ticket:

1. ¿Donde ocurre?
2. ¿Lo que sucede?
3. ¿Bajo qué circunstancias?

Un desarrollador experimentado solo necesitará echar un vistazo al título para comprender el problema. Por ejemplo:

Página de inicio de sesión: el campo no se resalta cuando se ingresa una contraseña incorrecta

Ambiente

A menudo he visto a evaluadores olvidarse de especificar en el ticket en qué entorno se produjo el problema. Esto es especialmente relevante en los tickets relacionados con la interfaz de usuario, donde la dirección del sitio web o la solicitud de red no son visibles. Indíquelo siempre. Si hay un campo independiente en el ticket, perfecto, inclúyalo allí. Si no es así, menciónelo en los pasos de reproducción, por ejemplo:

Inicie sesión en el entorno de prueba con una cuenta de administrador.

Hablando de pasos...

Pasos de reproducción

Una de las secciones más importantes son las instrucciones de reproducción de errores. Destacaré dos partes en las que centrarme: el formato de los pasos (visual) y el contenido (datos internos).

Parte visual

Mantener la estructura

Existen diferentes variaciones de informes de errores, pero clásicamente deberían contener las siguientes secciones:

1. Pasos
2. Resultado esperado
3. Resultado real

Utilice esta estructura y manténgala siempre. Este es uno de esos casos en los que la uniformidad le ayudará a organizar sus ideas a la hora de describir el tema.

Utilice una lista numerada

Divida los pasos utilizando una lista numerada. A veces, los evaluadores escriben descripciones detalladas, pero como un bloque de texto continuo. No haga esto. Será mucho más fácil para todos leer si los pasos están separados.

Siempre que sea posible, escriba sin errores gramaticales.

Ahora, pasemos al contenido de estos pasos.

El sentido común en las descripciones

No es necesario dividir cada acción en un paso independiente si no es crucial para reproducir el error; esto es difícil de leer y usar en la práctica. No tenga miedo de incluir múltiples acciones en un solo paso. ¿A qué me refiero?

Malo :

1. Vaya a test.com/login

2. Haga clic en el campo de inicio de sesión

3. Ingresar el login

4. Haga clic en el campo de contraseña

5. Introduzca la contraseña

   
   

Bien :

1. Vaya a test.com/login e inicie sesión con cualquier cuenta

No desglosamos los pasos en cosas que el desarrollador hará naturalmente mientras sigue el flujo estándar. Cuando estaba empezando, solía pensar que cada acción necesitaba su propio paso, pero no es necesario.

Evite la ambigüedad

Complemente siempre los pasos con la solicitud específica a verificar en cada paso y escriba el botón específico a presionar (especialmente si hay botones con el mismo nombre).

Incluir datos de prueba

Proporcione datos de inicio de sesión si el error está relacionado con su cuenta y no dude en incluir cargas de prueba que ayuden a reproducir el error.

Revisa tus pasos nuevamente

A veces, escribes los pasos inmediatamente después de encontrar el error, pero puede resultar que te hayas saltado un paso para comprenderlo por completo o que el error no se pueda reproducir más adelante. En ese caso, puede que sea necesario encontrar pasos más precisos.

Resultado esperado

Una sección aparte es el resultado esperado, donde describimos (como era de esperar) el resultado que se espera cuando se siguen los pasos. No hay muchas recomendaciones especiales aquí, salvo que esta sección debe existir: el desarrollador debe comprender qué comportamiento debe generar la funcionalidad. Frases como "todo debería funcionar bien" no son suficientes: escriba el comportamiento específico.

Resultado real

Aquí escribimos lo que realmente sucedió cuando seguimos los pasos. La especificidad también es importante aquí. No escribas simplemente “todo se rompió” (aunque probablemente eso fue lo que sucedió). Describe los indicadores que muestran que todo se rompió. Por ejemplo:

Se devuelve un error 500 en la solicitud GET /accounts y se bloquea la interfaz de usuario. El usuario no puede salir de la página ni hacer clic en los elementos.

Actualizar la página activa nuevamente la solicitud y genera el mismo error.

En otras palabras, describe el efecto real y cómo impacta el flujo del usuario.

Archivos adicionales

Esta es una sección aparte que vale la pena mencionar. Es donde se adjunta información adicional que describe el error. Conozco a algunos desarrolladores a los que no les gusta leer los pasos de reproducción y van directamente al resultado real y a los materiales adicionales que lo explican.

Capturas de pantalla del error

Es mejor verlo una vez que oírlo cien veces. Es una excelente manera de mostrar visualmente qué está sucediendo y dónde. Intenta siempre adjuntar una captura de pantalla.

Pedido

Si hay una solicitud en la que se produjo el error, siempre debe incluirse en el ticket. Sin embargo, las solicitudes contienen muchos parámetros diferentes. Resalto los siguientes como importantes para incluir:

• URL de error : la solicitud en sí, que puede obtenerse desde la sección Red del navegador donde se está realizando la prueba.

• Métodos : GET , POST , TRACE , OPTION , etc. Existen muchos métodos, al igual que existen solicitudes con la misma URL pero con métodos diferentes. No olvides especificarlo en el ticket.

• Código de error : otro punto importante. Probablemente no lo olvides, pero no olvides anotar qué código te devolvió el servidor.

• Carga útil : son los datos que enviamos en nuestra solicitud al servidor. No están presentes en todas las solicitudes (por ejemplo, HEAD o GET no los tienen), pero podrían ser la causa del error.

• Respuesta : la respuesta del servidor. A veces, contiene el error completo e incluso muestra dónde ocurrió, mientras que otras veces es solo un marcador de posición predeterminado que se configura en el backend para ese tipo de error. Asegúrese de incluir esto: le ahorrará mucho tiempo al desarrollador.

Registros de la consola

A veces, se encuentran errores en la consola y estos se pueden agregar al ticket. Quizás ya lo hayas hecho, pero solo quiero señalar que siempre se puede guardar un bloque grande de texto como un archivo .log y agregarlo al ticket. Esto mejora la legibilidad tanto de los registros como del ticket en sí.

Todo esto está muy bien, pero...

Todo esto está muy bien, pero ¿dónde encontraremos el tiempo para que todo se vea tan bien? Se acercan los plazos, el gerente se está enojando, hay un obstáculo en la producción y me piden que me siente y escriba todo. Simplemente le enviaré un mensaje al desarrollador directamente y eso es todo.

Este es un argumento lógico que puede surgir. No me hago ilusiones sobre el mundo perfecto de un tester, donde se asigna suficiente tiempo para las pruebas, todo se realiza según un proceso y se mantiene una documentación minuciosa y de alta calidad. Lo entiendo, pero a menudo hay escasez de tiempo, se queman... bueno, ojos y hay una carrera para terminar todo a tiempo.

Los pequeños errores tienden a acumularse, requieren más tiempo debido al cambio de contexto y conducen a malas prácticas. Si comenzamos a implementar mejoras gradualmente y a monitorear su funcionamiento, podremos crear un proceso más estable, estandarizado y predecible para todos los participantes.

El gerente de proyecto comprenderá lo que está sucediendo con el producto sin necesidad de llamar a todos para obtener actualizaciones, el desarrollador no tendrá que pedirle al evaluador que aclare las condiciones de reproducción y no lo alejará de las pruebas, y las partes interesadas, a su vez, tendrán una visión clara del progreso del producto.

Este artículo está más orientado a principiantes que están empezando o ya han empezado su camino en el mundo de las pruebas. Creo que los pequeños pasos conducen a grandes resultados, y las recomendaciones de este artículo darán lugar a informes de errores de mayor calidad.

Si tienes alguna pregunta, sugerencia, desacuerdo o queja, no dudes en dejarla en los comentarios. ¡Me interesa conocer tu opinión!