Reportar errores es un acto de diseño
Un buen reporte de bug no solo describe un problema: ahorra horas al equipo, acelera el fix y elimina ambigüedad. Esta es la estructura que uso para que cada caso se entienda a la primera.
Principios del reporte
Antes de tocar el teclado, estas son las reglas que definen el cómo y el porqué de cada reporte.
Reproducible al 100%
Si no se puede reproducir, no es un bug, es una observación. Cada paso está numerado y verificable.
Contexto, no opiniones
Se describe el comportamiento observado y el esperado. La calificación del impacto la pone el negocio.
Evidencia visible
Capturas, grabaciones y archivos adjuntos. Un buen reporte se entiende sin abrir el ticket del lado.
Criterios claros
El fix no termina cuando "parece funcionar": termina cuando se cumplen los criterios de aceptación.
Cómo se construye un reporte
Cinco pasos secuenciales que sigo desde que detecto el caso hasta que queda listo para handover.
Identificar
Detecto el caso durante prueba exploratoria o regresión. Anoto el flujo exacto.
Validar
Reproduzco el bug en al menos 2 ciclos. Confirmo que no sea flake (intermitente real).
Evidencia
Tomo screenshots, grabo screen-recording y exporto logs si el caso lo requiere.
Redactar
Escribo el reporte con el template: título, descripción, pasos, esperado, obtenido, criterios.
Entregar
Subo el ticket con la prioridad correcta, asigno módulo y notifoco al responsable.
Cómo documento un bug
Cada reporte sigue la misma estructura interna (A→G). Las apps cambian, el método no.
Descripción
Dentro del flujo Escanear Factura, se muestra una pantalla informativa antes de permitir al usuario continuar con el escaneo. Al seleccionar "No volver a mostrar este mensaje", el sistema deja de mostrar la alerta mientras el usuario permanece con la sesión activa. Sin embargo, si el usuario cierra sesión y vuelve a ingresar, la alerta vuelve a mostrarse. Este comportamiento indica que la preferencia no se está guardando de forma persistente.
Pasos para reproducir
- Ingresar a la app con un usuario válido.
- Ir al flujo Escanear Factura.
- En la pantalla informativa, marcar la opción "No volver a mostrar este mensaje".
- Continuar con el flujo y verificar que el mensaje no vuelva a mostrarse durante la sesión activa.
- Cerrar sesión.
- Iniciar sesión nuevamente con el mismo usuario.
- Volver al flujo Escanear Factura.
- Observar que la pantalla informativa vuelve a mostrarse.
Resultado esperado vs. obtenido
La preferencia se guarda de forma persistente. La pantalla informativa no vuelve a mostrarse, incluso tras cerrar y abrir sesión.
La opción funciona solo dentro de la sesión activa. Al reingresar, el mensaje vuelve a aparecer.
Criterios de aceptación
- ✓La preferencia "No volver a mostrar este mensaje" debe guardarse de forma persistente.
- ✓La pantalla informativa no debe volver a mostrarse después de cerrar sesión e iniciar nuevamente.
- ✓La preferencia debe mantenerse asociada al usuario correspondiente.
- ✓Si otro usuario ingresa en el mismo dispositivo, debe respetarse la configuración propia de ese usuario.
- ✓El comportamiento debe validarse en Android y iOS.
- ✓Si el usuario no marca la opción, la pantalla informativa debe seguir mostrándose según el comportamiento definido.
Evidencia
Evidencia visual: flujo Escanear Factura. La zona marcada corresponde al checkbox afectado.
Descripción
Al cargar una factura, el sistema no muestra todos los productos visibles en el documento cuando no existen en el catálogo. En la factura se observan varios productos, pero en el detalle procesado solo aparecen algunos en la tabla Productos Extraídos. Los productos sin coincidencia deben listarse también, marcados como Sin coincidencia, para que el usuario pueda revisarlos o asociarlos manualmente.
Pasos para reproducir
- Ingresar al sistema con un usuario válido.
- Cargar una factura que contenga varios productos.
- Esperar a que el OCR procese la factura.
- Acceder al detalle de la factura desde el Backoffice.
- Comparar los productos visibles en la imagen con los productos en la tabla Productos Extraídos.
- Verificar que algunos productos visibles no aparecen en la tabla.
Resultado esperado vs. obtenido
Mostrar todos los productos leídos, incluso sin coincidencia, con estado Sin coincidencia para que el usuario los revise.
Solo se listan algunos productos. El sistema omite los productos visibles que no tienen coincidencia en el catálogo.
Criterios de aceptación
- ✓El OCR debe mostrar todos los productos leídos desde la factura.
- ✓Los productos sin coincidencia deben mostrarse con estado Sin coincidencia.
- ✓El sistema no debe omitir productos visibles solo porque no tengan coincidencia.
- ✓El usuario debe poder revisar manualmente los productos sin coincidencia.
- ✓La cantidad de productos en el detalle debe coincidir con los detectados por OCR.
- ✓La información debe incluir nombre, cantidad, precio y total cuando estén visibles.
- ✓El comportamiento debe aplicarse a todas las facturas procesadas.
Evidencia
Evidencia visual: Backoffice · Detalle de Factura. La factura contiene 3 productos · la tabla solo lista 2.
Cómo cubro un feature antes de que se desarrolle
Feature solicitado: el banner del tablero debe contabilizar facturas pendientes y puntos reconocidos.
⌖ Banner a probar⌖ App: PulsoSolicitud del cliente
Dentro del banner del tablero (Mi Tablero), se deben contabilizar todas las facturas pendientes, incluyendo las que tienen puntos reconocidos y las que no.
- Contar facturas en estado pendiente.
- Sumar puntos reconocidos de cada factura pendiente.
- No contar facturas aprobadas, rechazadas, canceladas o procesadas.
- Mostrar el contador en formato:
🧪 Casos de prueba (20)
| ID | Escenario | Escena / caso | Datos de prueba | Resultado esperado | Categoría |
|---|---|---|---|---|---|
| CP-01 | Conteo base | Usuario sin facturas pendientes | 0 facturas pendientes | El banner no se muestra o muestra 0 facturas pendientes · 0 pts reconocidos, según diseño definido. | Conteo base |
| CP-02 | Conteo base | Una factura pendiente con puntos reconocidos | 1 factura pendiente con 20 pts | El banner muestra 1 factura pendiente de revisión · 20 pts reconocidos. | Conteo base |
| CP-03 | Conteo base | Una factura pendiente sin puntos reconocidos | 1 factura pendiente con 0 pts | El banner muestra 1 factura pendiente de revisión · 0 pts reconocidos. | Conteo base |
| CP-04 | Conteo base | Varias facturas pendientes con puntos | 2 facturas pendientes: 10 pts + 30 pts | El banner muestra 2 facturas pendientes de revisión · 40 pts reconocidos. | Conteo base |
| CP-05 | Conteo base | Varias facturas pendientes sin puntos | 2 facturas pendientes: 0 pts + 0 pts | El banner muestra 2 facturas pendientes de revisión · 0 pts reconocidos. | Conteo base |
| CP-06 | Conteo base | Facturas pendientes mixtas | 1 factura con 40 pts + 1 factura con 0 pts | El banner muestra 2 facturas pendientes de revisión · 40 pts reconocidos. | Conteo base |
| CP-07 | Conteo base | Múltiples facturas mixtas | 5 pendientes: 10, 0, 20, 0, 30 pts | El banner muestra 5 facturas pendientes de revisión · 60 pts reconocidos. | Conteo base |
| CP-08 | Estados | Facturas aprobadas no deben contarse | 1 pendiente + 2 aprobadas | Solo se cuenta la pendiente. El banner muestra 1 factura pendiente. | Estados |
| CP-09 | Estados | Facturas rechazadas no deben contarse | 1 pendiente + 2 rechazadas | Solo se cuenta la pendiente. El banner muestra 1 factura pendiente. | Estados |
| CP-10 | Estados | Facturas en otros estados no pendientes | Facturas aprobadas, rechazadas, canceladas o procesadas | No deben afectar ni el conteo ni los puntos reconocidos. | Estados |
| CP-11 | Edge case | Factura pendiente con puntos nulos | Pendiente con points = null | Debe contarse como factura pendiente y los puntos deben tratarse como 0. | Edge case |
| CP-12 | Edge case | Factura pendiente con puntos en decimal, si aplica | 1 factura con 10.5 pts | Validar si el sistema permite decimales o debe redondear. | Edge case |
| CP-13 | Edge case | Singular/plural del texto | 1 factura pendiente | Debe decir 1 factura pendiente, no 1 facturas pendientes. | Edge case |
| CP-14 | Sincronización | Actualización después de escanear factura | El usuario escanea una factura nueva pendiente | El contador aumenta inmediatamente o después de refrescar, según comportamiento esperado. | Sincronización |
| CP-15 | Sincronización | Actualización después de aprobación | Una factura pendiente pasa a aprobada | El contador de pendientes disminuye y los puntos reconocidos se actualizan. | Sincronización |
| CP-16 | Sincronización | Actualización después de rechazo | Una factura pendiente pasa a rechazada | El contador disminuye y sus puntos dejan de sumarse. | Sincronización |
| CP-17 | Multi-farmacia | Usuario con varias farmacias | El usuario cambia de farmacia activa | El banner debe mostrar solo las facturas pendientes de la farmacia seleccionada. | Multi-farmacia |
| CP-18 | Sincronización | Pull to refresh / botón refrescar | Cambian datos en backend | El banner debe actualizar la cantidad y los puntos correctamente. | Sincronización |
| CP-19 | Errores | Error de carga de datos | Backend no responde | Mostrar estado controlado: loading, error o mantener último dato válido, según diseño. | Errores |
| CP-20 | Errores | Usuario sin conexión | App offline | No debe mostrar datos incorrectos; debe manejar el estado offline correctamente. | Errores |