"No funciona" no es un reporte de bug, es una pista. La diferencia entre un bug que un desarrollador soluciona en minutos y uno que va y viene con preguntas durante días casi nunca está en la gravedad del error — está en qué tan bien está reportado.
Lo mínimo que necesita todo reporte
- Pasos para reproducirlo: en orden, empezando desde una pantalla conocida. Si no reproduce siempre, decir con qué frecuencia pasa ("3 de cada 5 intentos") es más útil que omitirlo.
- Resultado esperado vs. resultado real: qué debería haber pasado, y qué pasó en realidad. Sin este contraste, quien lee el reporte tiene que adivinar cuál era el comportamiento correcto.
- Entorno: navegador, dispositivo, usuario o rol con el que se probó, y en qué ambiente (producción, staging). La misma falla puede no reproducir en otro entorno, y esa diferencia suele ser justamente la pista que resuelve el bug.
- Evidencia: una captura de pantalla o un video corto ahorra varias idas y vueltas de "¿me puedes mandar una captura?".
La severidad no es solo "qué tan feo se ve"
Es común confundir severidad con lo visualmente notorio. Un botón mal alineado es molesto pero de baja severidad; un cálculo de precio equivocado que nadie nota a simple vista es de severidad alta, aunque la pantalla se vea perfecta. Vale la pena definir la severidad según el impacto real (pérdida de datos, bloqueo de un flujo crítico, riesgo de seguridad) y no según qué tan visible es el problema.
Un bug, un reporte
Igual que con los casos de prueba, meter varios problemas distintos en un solo reporte complica el seguimiento: uno se resuelve y el otro no, pero el estado del reporte queda ambiguo. Un reporte por problema, aunque parezcan relacionados, deja mucho más claro qué está resuelto y qué sigue pendiente.
Vincula el bug al caso de prueba que lo encontró
Cuando un bug queda conectado al caso de prueba que lo originó, es mucho más fácil saber qué volver a ejecutar una vez que se corrige, y con el tiempo se empieza a ver qué áreas del producto generan más bugs — información valiosa para decidir dónde reforzar las pruebas.
Esa trazabilidad (caso de prueba → ejecución → bug → estado) es exactamente lo que QAcove organiza automáticamente en un solo lugar, en vez de tener los casos en una hoja de cálculo y los bugs sueltos en otra herramienta sin conexión entre ambos.