Siempre hacemos un esfuerzo muy grande por evitar cometer errores, pero a veces no es suficiente y es posible que algo se nos escape. Cuando esto sucede los clientes (en nuestro caso las agencias) nos avisarán de los bugs encontrados para que podamos corregirlos. Sin embargo, a veces los reportes no están lo suficientemente completos como para que podamos rastrear el error y encontrar el problema para poder solucionarlo.

En proyectos grandes y a largo plazo lo ideal es tener un sistema de bug tracking, pero para trabajos medianos o pequeños consideramos que un sistema de este tipo genera más problemas que beneficios y con un simple correo electrónico es suficiente. Sin embargo, esto no quita que el reporte de error deba estar completo.

Qué debe contener un reporte de bug

Todo reporte de error debe estar lo suficientemente detallado como para que los programadores podamos reproducirlo en igualdad de condiciones. No es suficiente con avisarnos que algo no funciona, debemos saber exactamente qué es lo que no funciona y por qué se considera que es un error, ya que muchas veces no se trata de un error sino de una mala interpretación sobre la forma en que debería estar funcionando el programa.

Un reporte de error debería responder al menos estas 4 preguntas:

  1. Cuáles son los pasos a seguir para producir el error
  2. Qué resultado esperaba conseguir el usuario al ejecutar estos pasos
  3. Qué resultado se obtuvo en lugar del esperado
  4. Bajo qué condiciones se ejecutó la prueba: sistema operativo usado, versión del navegador o teléfono móvil, resolución de pantalla, etc.

También resulta de mucha ayuda incluir capturas de pantallas, archivos adjuntos o imágenes que se hayan utilizado, copias completas de direcciones de acceso (URL), datos que se usaron para completar formularios, etc.

Si los reportes de errores están completos ahorraremos mucho tiempo en idas y vueltas de emails y lograremos entregar los trabajos con mayor anticipación.