Entre todas las cosas relacionadas con las pruebas, los informes de error son algo a lo que un tester se enfrenta a diario. Estos documentos describen un error, su gravedad y prioridad, y los pasos para reproducirlo. Con base en los informes de error, los desarrolladores pueden determinar rápidamente qué parte del código no está funcionando correctamente y repararlo.
Un informe de error bien escrito garantiza una colaboración eficaz entre los equipos de desarrollo y de pruebas. Por lo tanto, la capacidad de escribir informes de error es una de las habilidades más importantes de un tester.
Por Qué Necesitamos Informes de Error
¿Por qué no podemos reparar los errores inmediatamente? ¿Por qué necesitas escribir informes? Escribir informes de error es esencial porque:
1. Hay documentación sobre la existencia de un error.
Hay un informe, hay un registro del problema. No debes escribir los errores a través de Skype/chat ni hablarlos en persona, etc. Existe la posibilidad de que alguien lo olvide (incluyéndote) y no lo repare. Entonces el usuario o el cliente (durante las pruebas de aceptación) detectarán el error, y es poco probable que estén felices con ello.
2. Los informes de error ayudan al desarrollador.
Para reproducir el error y luego corregirlo, los desarrolladores necesitan información. Los informes de error deben ser lo más precisos, completos y comprensibles posible. Sin una documentación completa, el desarrollador tendrá que invertir tiempo en la búsqueda y análisis del error.
3. Se vuelve posible darle prioridad a las reparaciones.
Si tienes muchos errores, siempre tendrás que elegir cuál reparar primero ya que no podrás reparar todo al mismo tiempo.
4. Se vuelve posible analizar los errores.
Tener información sobre los defectos te permite determinar el origen y realizar cambios en los procesos de trabajo para prevenir errores.
5. El tester contribuye a la reparación del error.
Un informe de error bien elaborado es de enorme ayuda para los desarrolladores porque les permite determinar rápidamente dónde está el error y repararlo.
6. Se vuelve posible controlar en qué fase reparas el error.
Ya sabes que antes de repararlo, cada error pasa por ciertas fases de su ciclo de vida. La presencia de un informe de defecto con un estatus cambiante te permite determinar rápida y fácilmente la “posición” exacta del error y controlar su corrección.
7. Se vuelve posible evaluar la calidad actual del producto.
Supón que, durante las pruebas, se encontraron 50 errores, y todos ellos se registraron como informes de error. Como gerente, serás capaz de evaluar la disponibilidad del producto, evaluar el número de mejoras requeridas, tomar decisiones sobre el lanzamiento, etc. Los informes de defectos proporcionan a los equipos información benéfica y esencial para controlar la calidad del producto.
Es por ello que la habilidad de escribir buenos informes es de vital importancia para cualquier tester profesional y se debe dominar.
Pasos para Escribir un Informe de Error
El informe de error se introduce en el sistema de seguimiento de errores (Jira, Trello). Consiste en un título, descripción y diversos campos (tareas asociadas, equipo, diseñador, etiquetas, prioridad) que se llenan o no, dependiendo del proyecto.
El título debe ser corto y descriptivo. La esencia del problema debe quedar clara en el título. Generalmente, el título se redacta de acuerdo al principio “¿Qué? ¿Dónde? ¿Cuándo?”. Por ejemplo:
Qué — Abre una lista desplegable vacía
Dónde — en la página principal
Cuándo — al hacer clic sobre ella.
La descripción de un informe de error puede diferir de un proyecto a otro, pero estas son las secciones generales:
1. Una descripción más detallada del problema que en el título.
2. Descripción del estado inicial del sistema y otros datos sobre el entorno:
- El navegador y su versión
- Entorno de pruebas: dev, stage, prod
- El dispositivo en el que se realizó la prueba: teléfono móvil, tableta, computadora de escritorio con su sistema operativo
3. Pasos para reproducir el error.
Todos los verbos se escriben en infinitivo. No necesitas escribir “Presioné el botón”. Sería más correcto escribir “hacer clic en el botón” / “abrir la cesta” / “página de inicio”. Los pasos están numerados. Si necesitas abrir un recurso de terceros, adjunta un link entre paréntesis.
4. Describe el resultado real.
Incluye el texto más una captura de pantalla o un video. Debes grabar el video sin sonidos extraños, a menos que se pruebe un componente del programa que involucre sonido. Otros sonidos de fondo pueden distraer y resultar molestos. Si el video es grande o no hay forma de adjuntarlo directamente al sistema de seguimiento de errores, puedes subirlo a Google Drive y pegar un link hacia él (siempre revisa el link y los permisos antes de pegarlo).
Al insertar una captura de pantalla, primero debes marcar el error. Rodéalo con un rectángulo de un color que resalte; generalmente se usa el rojo. Luego, puedes describir el resultado esperado justo sobre la foto.
Si hay datos de entrada, asegúrate de registrarlos. Si el monto está mal calculado, entonces proporciona los datos para los números usados. Si un campo no se valida correctamente, proporciona los datos usados al llenarlo.
5. Describe el resultado esperado.
Incluye el texto o una captura de pantalla (si se trata de un error en la interfaz de usuario) de los requisitos. En ocasiones, puedes combinar en una foto los resultados reales y los esperados para mayor claridad. Una sola foto es más fácil de explorar para el desarrollador ya que no necesita estarse moviendo de una a otra imagen.
6. Establece la prioridad y gravedad.
Por lo general, la “prioridad” y “gravedad” se muestran en listas desplegables separadas de la descripción. El tester las establece pero el desarrollador o el PM pueden corregirlas posteriormente.
Prioridad:
- P1 Alta (urgente)
- P2 Media (puede esperar)
- P3 Baja (no urgente)
Gravedad:
- Bloqueante (altera el desempeño)
- Crítico (afecta significativamente)
- Mayor (distorsiona la información mostrada pero no produce cambios notables)
- Menor (no afecta el funcionamiento del programa)
7. Asígnaselo al desarrollador o al PM.
8. Haz clic en “done”. :)
El Ciclo de Vida de un Informe de Error
- Open (Abierto) — creaste un informe de error y se lo entregaste al desarrollador/PM (de manera que el PM pueda asignárselo a un desarrollador). El error puede irse al backlog, un lugar especial donde los errores esperan a ser seleccionados y enviados a desarrollo. Es como los jugadores en la banca esperando su oportunidad para jugar.
- In Work (En curso) — el error se transfiere al desarrollador para que lo repare.
- Fixed (Listo para Diseño/QA) — el desarrollador reparó el error y se lo envió al diseñador (si hay uno en el equipo) o al tester para que vuelva a revisarlo. Si resulta que el error no se ha reparado, se devuelve al desarrollador (es recomendable adjuntar un informe con foto/video de que el error sigue apareciendo).
- Closed — el error se ha verificado y ya no se reproduce. Al cerrar un error, el tester escribe en los comentarios en qué entorno se probó y adjunta una captura de pantalla o video de que el error realmente está reparado. Esta última acción confirma que el error se reparó en caso de que vuelva a aparecer más adelante y surjan dudas.
Errores Principales Al Escribir Informes de Error
1. El título es incomprensible o demasiado largo.
Tienes que leerlo varias veces para obtener una idea general.
2. Los datos de la descripción son insuficientes o faltan capturas de pantalla.
Dicho informe de error se enviará de ida y vuelta del desarrollador al tester, o el desarrollador necesitará invertir un largo tiempo para encontrar todos los datos necesarios. Por lo tanto, es clave escribir desde el principio un informe de error detallado.
3. Los informes de error están repetidos.
Si hay más de un tester en el proyecto, debes verificar si es el mismo informe de error.
4. Un problema, un informe.
No es necesario insertar muchos errores diferentes en un informe si no están relacionados entre sí.
5. El resultado esperado menciona los requisitos sin especificar la sección exacta.
El desarrollador perderá tiempo leyendo el documento completo (o te devolverá el informe de error). Al adjuntar los requisitos, es necesario indicar en qué sección y párrafo se encuentra la información esencial. Si las condiciones requieren solo un par de líneas, adjunta una foto de estas líneas. Esto le ahorrará tiempo al desarrollador, ya que no será necesario descargar todo el documento y echarle un vistazo.
En Conclusión
Si tu informe de error está escrito correctamente, las posibilidades de reparar un error rápidamente son mayores. Por lo tanto, reparar un error depende de qué tan bien lo reportes. El punto de escribir un informe de error es reparar los problemas. Por eso, escribir los informes de error adecuados es una habilidad esencial y necesita desarrollarse.