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   refactorizando el código. ver anime  Mi nombre es   , soy un   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. Evgeny Domnin QA   Título  Intente responder tres preguntas en el título del ticket:   ¿Donde ocurre?   ¿Lo que sucede?   ¿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:  Pasos  Resultado esperado  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  Vaya a  test.com/login  Haga clic en el campo de inicio de sesión  Ingresar el login  Haga clic en el campo de contraseña  Introduzca la contraseña    : Bien  Vaya a   e inicie sesión con cualquier cuenta test.com/login  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:    solicitud    Se devuelve un error 500 en la 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:    : la solicitud en sí, que puede obtenerse desde la sección Red del navegador donde se está realizando la prueba. URL de error    :   ,   ,   ,   , 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. Métodos GET POST TRACE OPTION    : otro punto importante. Probablemente no lo olvides, pero no olvides anotar qué código te devolvió el servidor. Código de error    : 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. Carga útil    : 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. Respuesta  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   y agregarlo al ticket. Esto mejora la legibilidad tanto de los registros como del ticket en sí. .log   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!

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Read My Stories

Este audio es producido en el idioma original de la historia!

Cómo redactar buenos informes de errores: recomendaciones

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps